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FOREWORD 


This  project  was  funded  by  the  Offiee  of  the  Secretary  of  Defense  under  Intra-Army  Order  22 
MSS-88-088,  "Enhancement  of  the  Early  Environmental  Warning  System,"  dated  September  1988.  The 
proceedings  were  prepared  by  the  U.S.  Army  Construction  Engineering  Research  Laboratory 
Environmental  Division  (USACERL-EN).  D;.  R.K.  Jain  is  Chief  of  USACERL-EN. 

COL  Carl  0.  Magncll  is  Commander  and  Director  of  L'SACERL,  and  Dr.  L.R.  Shaffer  is 
Technical  Director. 


Preface 


The  Geographical  Resource  Analysis  Support  System  (GRASS)  is  a  land  management  support 
tool  originally  developed  to  help  military  installations  ensure  realism  in  training  while  conserving  the 
environment.  Since  its  successful  implementation  in  the  military  community,  GRASS  has  seen 
widespread  acceptance  in  both  the  Government  and  private  sector. 

The  U.S.  Army  Construction  Engineering  Research  Laboratory  (USACERL)  developed  and  tested 
GRASS,  which  is  a  geographic  information  system  (G1S).  Now,  along  with  a  formal  GRASS  Stecrinc 
Committee  and  other  service  agencies,  USACERL  is  providing  support  to  users.  Each  year  the  Steering 
Committee  sponsors  a  user  group  meeting  for  information  exchange:  other  help  is  available  through 
workshops,  and  online  mail  service  called  GRASSNET,  and  a  periodical  newsletter,  GRASS- 
CL  1PPINGS. 

At  the  1 987  Annual  I'scr  Group  Meeting,  response  to  the  call  for  papers  was  so  favorable  and 
the  quality  of  presentations  so  impressive  that  the  organizers  decided  to  publish  the  papers  from  future 
meetings.  This  proceedings  contains  papers  from  the  1988  Annual  GRASS  User  Group  Meeting  which 
was  held  at  USACERL.  in  Champaign,  IL. 

The  papers  represent  a  variety  of  interests.  They  have  been  grouped  under  three  general  topic 
areas:  Applications,  Data  Concerns,  and  Integration  of  Grass  With  Other  Packages. 

Papers  in  the  Applications  group  illustrate  the  versatility  of  the  GRASS  software.  Gary 
W  aggoner  of  the  National  Park  Service  (NPS)  outlines  a  procedure  to  define  road  corridors  using 
GRASS.  Two  papers  deal  with  sampling  design:  Susan  Stitt,  NPS,  applies  GRASS  for  determining 
forest  locations  to  sample  in  evaluating  the  effects  of  air  quality  on  vegetation;  Steven  Warren, 
USACERL  uses  GRASS  to  define  areas  where  data  collection  sites  should  be  distributed  to  ensure 
nonbiased  data.  GRASS  applications  in  archeology  are  also  reported.  Ishmael  Williams  of  the 
Arkansas  Archeoloj.1..,!  Survey  (AAS)  describes  how  he  uses  GRASS  to  organize  his  data  to  reveal 
patterns  of  the  Caddo  Indian  habitation  sites.  Jamie  Lockhart,  AAS,  uses  GRASS  to  coordinate  and 
represent  statistical  and  ordinal  archeological  information  over  an  eight-slate  region.  Pamela  Thompson, 
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USACERL,  demonstrates  the  versatility  of  soils  information  when  handled  with  the  GRASS  tools  as 
well  as  several  potential  new  applications.  David  Hasting  of  the  National  Oceanic  and  Atmospheric 
Administration  user  GRASS  to  check  the  quality  and  consistency  of  the  spatial  data  for  which  his 
agency  is  responsioie. 

Presentations  in  the  Data  Concerns  group  address  the  information  base,  which  critical  if  a  G1S 
like  GRASS  is  to  be  useful.  Since  data  collection  is  expensive,  it  is  important  to  know  which  data 
layers  to  implement,  and  this  is  the  topic  of  a  paper  by  Robert  Lozar  of  USACERL.  Richard 
Franchek,  U.S.  Soil  Conservation  Service  (SCS),  describes  and  example  data  set  for  training  personnel 
at  SCS,  where  GRASS  will  soon  be  implemented  in  all  county  offices.  Margaret  Mayers  of  SPOT 
Image  Corp.  discusses  the  link  between  satellite  data  and  GRASS-an  important  capability  since  satellite 
images  can  provide  valuable  data. 

GRASS  is  designed  to  allow  easy  interface  with  other  software  packages  for  flexibility.  Papers 
in  the  GRASS  Integration  group  attest  to  the  success  users  are  having  in  this  area.  Sandra  Parker, 
AAS,  proposes  linking  a  statistical  package  with  GRASS  and  remotely  sensed  data  to  make  the  results 
more  immediately  understandable  to  professionals.  Sanford  Fidcll  and  colleagues  from  BBN  Systems 
describe  how  they  ported  sections  of  GRASS  version  2.0  to  an  IBM-AT  with  MS-DOS  and  their 
integration  with  a  data  base  manager  (DBM)  for  evaluating  aircraft  noise.  James  Farley,  AAS, 
discusses  the  interface  of  GRASS  with  a  UNIX-based  DBM  called  Informix.  Finally,  Ken  Gardels, 
at  the  University  of  Califomia-Berkcley,  identifies  the  pros  and  cons  of  placing  GRASS  in  a  new 
standard  graphics  environment  called  X-Windows. 

In  the  short  time  since  its  inception,  the  potential  for  GRASS  has  grown  far  beyond  initial 
expectations.  Each  year  the  User  Group  Meeting  unveils  more  and  more  benefits  from  using  this 
program;  the  enthusiasm  users  have  for  GRASS  is  evident  in  these  papers.  Today  GRASS  faces  and 
exciting  future  as  it  expands  and  secs  adoption  by  a  variety  of  new  organizations.  You  are  invited  to 
share  your  experiences  at  the  next  User  Group  Meeting  and  to  learn  how  others  arc  using  GRASS. 

For  more  information  on  GRASS  or  the  Annual  User  Group  Meeting,  contact  the  GRASS 


Support  Center  at  USACERL,  (217)  373-7220. 
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Analysis  of  Alternative  Road  Alignments  using  GRASS  3.0 

Gary  S.  Waggoner 

Geographic  Information  Systems  Division 
National  Park  Service 
P.O.  Box  25287 
Denver.  CO  80225-0287 


JBSTRACT 


A  "real  life"  example  using  GRASS  3.0  GIS  technology  to  aid  planners  in 
developing  a  new  park  entrance  rr  j  alignment  at  Great  Basin  National  Park, 
Nevada  is  presented.  Analyses  and  plots  have  been  field  tested  by  National 
Park  Service  and  Federal  Highway  Administration  planners.  GRASS  3.0  tools 
including  distance,  weight,  Gcost,  Gdruin,  and  Glos  were  employed  in  the  ana¬ 
lyses  and  are  discussed  in  light  of  the  field  cheeking  results. 


Great  Basin  National  Park  was  esta¬ 
blished  on  October  27,  1986  making  it  the 
newest  national  park  in  the  National  Park 
%stem.  Located  in  White  Pine  County,  in 
east-central  Nevada,  the  park  occupies 
77,109  acres  in  the  South  Snake  Range.  It 
was  established  "to  preserve  for  the  benefit 
and  inspiration  of  the  people  a  representa¬ 
tive  segment  of  the  Great  Basin  of  the 
Western  United  States  possessing  outstand¬ 
ing  resources  and  significant  geological  and 
scenic  values."  ( Public  Law  99-565) .  The 
National  Park  Service  (NPS)  is  currently 
preparing  a  general  management  plan  for  the 
park  (NPS,  1988)  and  a  GIS  data  base 
including  multiple  resource  themes  encom¬ 
passing  a  928  square  mile  area  is  being 
created  to  support  this  activity. 

One  of  the  proposals  being  considered 
is  the  building  of  a  Visitor  Center  in  the 
northeastern  portion  of  the  park  near  Baker 
Creek.  The  NPS  in  cooperation  with  the 
Federal  Highway  Administration  (FHA)  is 
charged  with  developing  a  new  park 
entrance  road  and  requested  the  GIS 
Division’ 8  support  in  this  undertaking. 

Since  the  GIS  Division  was  already 
conducting  a  beta  test  of  the  new  GRASS 
3.0  verson,  we  decided  to  test  several  of  the 
new  capabilities  with  a  "real  life"  experiment 


which  would  be  field  tested  to  give  some 
practical  evaluation  and  feedback. 

The  author  had  several  meetings  with 
NPS  planners  to  fully  discuss  the  intent  and 
parameters  involved  in  the  test.  After  fully 
describing  the  hypothesis  of  the  experiment, 
criteria  for  the  selection  of  a  road  corridor 
and  a  geographical  window  were  decided 
upon  and  GRASS  3.0  operations  were 
begun.  The  planners  indicated  that  three 
in^jor  criteria  were  important  in  these  road 
alignment  considerations: 

1.  Slopes  should  be  7  degrees  or  less 

2  Stream  crossings  should  be  minimized 
and  where  necessary  should  be  at  right 
angles  to  the  stream 

3.  The  entrance  road  should  be  hidden  as 
much  as  possible  from  the  view  of  a 
visitor  at  the  proposed  new  visitor 
center 

Vegetation  was  not  considered  a  significant 
criterion  because  the  vegetation  throughout 
the  area  of  concern  is  a  fairly  homogeneous 
sagebrush- shad  sc  ale- grass  association.  Nar¬ 
row  riparian  zones  do  occur  but  are 
automatically  incorporated  into  the  30  meter 
cell  size  used  to  delineate  the  small  streams 
in  the  area 


Using  1 : 250.000  scale  digital  tnpu 
graphic  1DMA1  data  tiiai  had  previously 
been  processed  into  elevation,  slo[x-  and 
aspect  90  meter  cell  data  files,  the  slope  data 
were  reclassed  into  two  classes,  0-7  degree 
slopes  and  greater  than  7  degree  slopes. 
Stream  data  were  obtained  from  digital  line 
graph  •  DUG  data  at  tiie  1 :100,00(t  scale  ;tnd 
rasterized  into  30  meter  cel's. 


Yiewsiied  data  wen-  obtained  by  run 
ning  '■  dos  e  i  tlie  elevaUon  data  iivutionc-ii 
above.  A  UTM  coordinate  pair  was  digitized 
from  a  mylar  1:2-1. 00* ■  .-  .-ah-  quadrangle  on 
which  tiu*  planners  had  I  catch  the  [reposed 
site  of  tiie  Visitor  C.-nter,  Gios  was  run  ... 
extend  th  ougiiout  tiie  predetermined  win¬ 
dow  cf  interest  1 9000  meters-  as  viewed 
from  a  point  50  feet  above  ground  level. 
The  height  was  determined  to  conservatively 
sainate  tiie  maximum  viewshed  from  .  a* 
highest  {xi tenlit J  point  of  development  ai 
tiie  pmj/osed  visit:  r  center. 

Weight  WH'  next  used  o  create  a  cel! 
flic  which  integratin'  ail  -  f  the  environmen¬ 
tal  criteria.  The  planners  assisted  in  estab¬ 
lishing  relative  weights  for  tiie  environmen- 


tai  variables: 

SLOPE:  0  -  7  degrees  0 

7  degrees  10 

STREAMS:  non  stream  r 

stre.im  1.0 


VIEWSHED:  unseen  area  ■-  0 

seen  an- a  -  5 

Weights  wen?  integrated  in  an  additive 
fashion.  Class  v;Jues  resulting  from  execut¬ 
ing  weight  wen-  0,  5,  10,  15,  20,  and  25 
it  fleeting  all  tiie  various  combinations  of 
v  triable  weights.  Ilie  resultant  c;ui  be 
desenbed  as  «n  "environmental  cost  map" 
depicting  tiie  interaction  of  till  the  variables 
considered  in  tiie  analysis. 

Gcost  was  tiien  run  on  tiie  "environ¬ 
mental  cost  map."  Gcost  evaluates  a  cost 
surface  relative  to  a  stalling  point.  It  estab¬ 
lishes  tiie  starting  [mint  as  a  Tow  point" 
which  the  user  selects  by  entering  a  UTM 
coordinate  pair.  This  point  serves  as  one  of 
two  or  more  jxiints  to  be  connected  in  tiie 
next  step  of  tiie  process  ie.  Gdrain.  A  cell 
map  similar  to  an  elevation  map  is  created 
which  i  valuates  the  environmental  cost  of 


getting  to  each  and  every  cell  in  the  window 
from  this  starting  point.  The  point  was 
selected  by  the  planners  to  represent  an  area 
near  an  existing  road  which  would  be  used 
to  access  tiie  proposed  Visitor  Center.  One* 
again  tiie  point  was  accurately  delineated  on 
a  mylar  1:24,000  scale  quadrangle  sheet  and 
digitized  to  obtain  accurate  UTM  coordi 
nates. 

Following  tiie  creation  of  tiie  Gcost 
evaluation  surface,  c. drain  was  employ*  -1  to 
operate  on  this  file.  A  second  point  was 
selected  at  the  proposed  intersection  v.itii 
the  existing  State  Highway  48.  approxi¬ 
mately  2  miles  soutli  of  Baker,  Neva 'a. 
'rhis  mter.ection  point  was  digitized  from 
tiie  mylar  quadrangle  Uic-et  and  entemd  as  a 
••  -iqitiiT  d  Gdrain  variable  in  UTM  •■oordi- 
natc-s. 

Gdrain  is  essentially’  a  gravity  flow 
m  .‘.d  and  allows  tiie  user  to  connect  desig- 
nroed  points  along  tiie  path  of  least  resis¬ 
tance  (or  least  environmental  cost'.  It 
analyze.-  how  ftii  imaginary  raindrop  would 
dram  from  any  beginning  point  to  die  low- 
point  mi  ‘be  map.  If  the  "topography”  of  the 
map  is  in  actuality  a  synthesis  of  environ¬ 
mentally  sensitive  factors,  tiien  tiie  resulting 
drainage  p-Th  is  an  environmental  least  cost 
pad:  or  corridor  connecting  the  selected 
points. 

The  result  of  the  Gdrain  operation 
produced  a  corridor  for  acceptable  road 
development  comprised  of  sections  of  nar¬ 
row  road  alignment,  30  meters  wide,  and 
sections  of  broader  zones  of  acceptable  road 
corridor  hundreds  of  motel's  wide.  In  order 
to  select  a  specific,  30  meter  wide  road 
alignment,  within  the  broad  zones  of  the 
acceptable  road  corridor,  die  author  decided 
to  use  a  buffering  approach  which  would 
force  the  selection  of  die  shortest  route 
widiin  the  acceptable  zone. 

Distance  was  used  to  develop  a  buffer 
surface  with  237  concentric,  30  meter  wide, 
rings  emanating  from  the  initial  digitized 
point  ie.  die  "low  point"  from  the  Gcost  sur¬ 
face.  Each  ring  was  weighted  at  its  ring 
order  number  away  from  die  center  point 
eg.  1,  2,  3,  ....  Additionally,  the  unaccept¬ 
able  road  alignment  zone  was  weighted  at 
500  while  the  acceptable  road  corridor  zone 
was  weighted  at  0.  Weights  were  integrated 
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in  an  additive  fashion. 

The  resultant  environmental  cost  sur¬ 
face  map  was  operated  on  in  a  similar 
fashion  as  described  above  with  both  Gcost 
and  G drain.  The  result  of  these  sequential 
operations  was  the  creation  of  a  single,  30 
meter  wide.  6.5  mile  long  alignment  con¬ 
necting  the  two  points  and  occurring  onlj 
within  the  acceptable  road  corridor  zone  pre¬ 
viously  determined. 

The  narrow  road  alignment  was  then 
added  to  the  initial  broader  zone  corridor 
using  patch  Tliis  patched  file  was  in  trim 
patched  into  a  cell  file  with  existing  roads 
and  trails.  A  plot  at  1:12,000  scale  was  then 
produced  on  mylar  to  overlay  «  topographic 
map  which  die  NTS  and  FflA  planners  used 
in  the  field  to  verify  die  results  of  the 
analysis. 

During  die  Iasi,  week  in  September. 
>  PS  and  FHA  planners  went  to  Great  Basin 
National  Park  to  evaluate  die  results  of  the 
GRASS  10  road  alignment  analysis.  After 
extensive  field  work,  checking  numerous 
sites  along  the  GRASS  3.0- generated,  pro¬ 
posed  road  alignment,  planners  found  the 
alternative  to  be  acceptable  and  to  meet  the 
criteria  used  in  the  model.  They  were  very 
encouraged  by  the  results  of  the  field  test 
stating  diat  "the  corridor  mapping  was 
extremely  accurate  and  very  helpful."  fGoo- 
drich,  1988) .  Subsequendy,  the  FHA 
planner  in  charge  of  developing  the  final 
road  alignment  specifications  expressed  his 
desire  to  work  with  our  office  combining  the 
Great  Basin  data  in  GRASS  3.0  with  the 
technical  engineering  data  that  the  FHA 
CADD  system  produces.  'The  applications 
could  be  very  beneficial  to  both  agencies." 
( Goodrich  1988) .  Our  office  will  be  pursu¬ 
ing  this  opportunity 

NPS  plan*  hav.  been  further 
encouraged  tr  GIS  technology  by  the 
success  of  .  ipplication.  The  entire 
analysis  was  ux-omplished  within  a  few  day's 
and  was  compnen.'  e  and  thorough  in  its 
use  of  road  slignro  .t  selection  criteria  In 
spite  of  the  relatively  gross  digital  topo¬ 
graphic  data  used  in  the  analysis,  highly  use¬ 
ful,  unbiased  information  has  been  gen¬ 
erated  in  a  timely  fashion. 

This  application  is  also  significant 
because  it  further  emphasizes  the  usefulness 


of  GIS  technology  in  alternative  formula¬ 
tion,  in  addition  to  environmental  impact 
assessment,  where  it  has  been  most  fre¬ 
quently  used  in  the  NPS.  Although  the  use 
of  GIS  technology  is  far  from  routine  in  the 
NPS,  successful  applications  such  as  this  one 
help  to  build  a  track  record  and  develop 
realistic  expectations  in  the  eyes  of  park 
management  Once  realistic  expectations 
from  management  can  be  met  by  GIS  tech¬ 
nology  advancement,  routine  use  of  GIS  will 
occur.  Based  on  the  success  and  acceptance 
of  this  application,  GRASS  3.0  has  moved 
the  National  Park  Service  closer  to  routine 
use  of  GIS. 
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ABSTRACT 

Selection  of  representative  sites  for  land  condition  inventory  can  be  a 
time-consuming  and  subjective  task.  A  procedure  is  currently  being  developed 
hv  the  US  Army  Construction  Engineering  Re  arch  Laboratory  to  remove  sub¬ 
jectivity  and  automate  tlie  site  selection  process  for  military  installations.  The 
procedure  incorporates  satellite  imager/  and  digital  soil  surveys  in  the  Geo¬ 
graphic  Resources  Analysis  Support  System  environment.  A  military  installa¬ 
tion  is  stratified  by  imagery-derived  land,  over  categories  and  soil  senes.  Inven- 
toty  sites  are  allocated  in  a  stratified  random  fashion  based  on  the  percentage  of 
the  installation  occupied  by  the  various  unique  landcoven  soil  series  categories. 


Background 

The  US  Army  manages  approximately 
4.5  million  hectares  of  forest  and  rangeland 
in  the  United  States.  Increasing  demands  for 
more  frequent  and  larger  scale  military 
training  exercises  compatible  with  modern 
weaponry  systems  have  taken  a  toll  on  the 
land  and  natural  resources.  Some  military 
installations  have  experienced  undesirable 
shifts  in  plant  species  composition,  reduc¬ 
tions  in  vegetative  cover  and  accelerated  soil 
erosion.  \s  a  result,  field  training  realism 
has  diminished  and  the  longevity  of  the  land 
for  military  training  proposes  has  been 
threatened. 

In  an  effort  to  halt  the  degradation  of 
military  land,  the  US  Army  Construction 
Engineering  Research  Laboratory  is  develop¬ 
ing  an  Integrated  Training  Area  Manage¬ 
ment  (ITAM)  program  (1).  The  program 
seeks  to  enhance  natural  resource  conserva¬ 
tion  and  realistic  field  training  tlirough  the 
integration  of  military  training  requirements 
with  environmental  awareness  education. 


land  rehabilitation  efforts  and  land-use  plan¬ 
ning  based  on  the  capacity  of  the  land  to 
support  various  forms  of  military  training. 
Effective  land  management  is  dependent,  in 
large  part,  on  accurate  assessment  of  the 
quantity  and  quality  of  available  resources. 
Therefore,  a  mqjor  thrust  of  the  ITAM  pro¬ 
gram  is  to  inventory’  the  current  condition  of 
Army  training  lands  in  terms  of  factors  such 
as  soil  erosion  and  concealment  resources, 
and  monitor  trends  in  land  condition  over 
time  through  a  standardized  procedure 
known  as  Land  Condition-Trend  Analysis 
(LCTA)  (2). 

LCTA  incorporates  on-the-ground 
sampling  of  soils,  topography  and  vegeta¬ 
tion.  Vegetation  is  evaluated  with  both 
point-intercept  and  belt  transect  methods 
and  requires  a  minimum  area  of  100m  x 
6m.  Selection  of  representative  sampling 
sites  for  land  condition  inventory  can  be  a 
time-consuming  and  fiighly  subjective  task. 
The  purpose  of  this  research  is  to  develop 
an  automated,  objective  procedure  for  selec- 
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tfnn  of  land  condition  inventory  sites.  The 
procedure  utilizes  satellite  imagery,  soil  sur¬ 
veys  and  the  Geographic  Resources  Analysis 
Support  System  ( GRASS) . 

Discussion 

The  first  step  in  the  site  selection  pro¬ 
cess  is  to  acquire  a  SPOT  satellite  image  of  a 
given  military  installation.  Ideally,  the 
image  should  be  taken  at  the  time  of  year 
when  perennial  plant  growth  is  at  a  peak, 
Based  on  reflectance  in  the  green,  red  and 
near  infra-red  spectral  wavelength  bands,  an 
unsupervised  classification  is  performed.  All 
land  areas  outside  of  the  installation  boun¬ 
dary  are  masked  from  the  satellite  image 
prior  to  the  classification  to  prevent 
influence  from  extraneous  land  cover  types. 
\  maximum  of  20  spectrally  unique  land- 
vover  categories  are  permitted.  Due  to  the 
nature  of  remotely  sensed  imagery,  the 
landcover  categories  are  sensitive  primarily 
to  the  amount  of  vegetative  cover  and  gross 
physiognomic  differences  in  plant  communi¬ 
ties  and,  to  a  lesser  degree,  plant  species 
composition. 

The  resulting  landcover  data  layer  pro¬ 
vides  an  initial  stratification  for  the  site 
selection  process.  However,  a  single 
spectrally- recognized  landcover  category  may 
actually  represent  more  than  one  distinct 
plant  community.  This  may  be  due  to  the 
limitation  of  20  landcover  categories 
imposed  on  the  un supervised  classification 
algorithm  or  may  result  from  the  occurrence 
of  more  than  one  plant  community  with 
very  similar  spectral  reflectance  characteris¬ 
tics.  In  the  latter  case,  differences  in  plant 
species  composition  are  often  correlated  to 
differences  in  the  soils  that  support  the 
vegetation.  Therefore,  a  secondary 
stratification  based  on  soil  aeries  is  appropri¬ 
ate. 

Within  GRASS  a  digital  soil  series  data 
layer  is  superimposed  on  the  landcover  data 
lgyer.  A  GRASS  "macro"  algorithm  has 
been  written  that  causes  the  computer  to 
recognize  each  unique  landcover/ soil  combi¬ 
nation  as  a  separate  category.  The  unique 
combination  of  a  landcover  category  with  a 
soil  series  categoiy  may  occur  as  a  single 
polygon  or  as  a  series  of  spatially  disjunct 
polygons  across  the  installation.  Every 


occurrence  of  the  various  landcover/ soil 
categories  is  considered  a  potential  inventory 
site. 

Depending  on  the  amount  of  error 
inherent  in  the  imagery  and  soil  source  data, 
and  the  error  introduced  operationally 
through  data  manipulation,  geographic  infor¬ 
mation  system  products  may  possess 
significant  levels  of  error  (3).  Given  this 
possibility  of  error,  in  addition  to  the 
minimum  «r?a  required  for  the  land  condi¬ 
tion  field  sampling  method,  it  has  been 
estimated  that  the  landcover/ soil  polygons 
must  be  at  lepst  2  hectares  ( 5  acres)  in  size 
in  order  to  be  accurately  identified  and 
inventoried  in  the  field.  Therefore,  the 
GRASS  "macro"  that  recognizes  the  unique 
landcover/ soil  combinations  has  also  been 
written  in  a  form  that  eliminates  all 
polygons  that  fail  to  meet  this  user-defined 
minimum  area  requirement. 

An  additional  GRASS  algorithm  is 
used  to  randomly  select  polygons  as  field 
inventory  sites.  The  number  of  selected 
polygons  is  dependent  on  the  size  of  the 
military  installation.  The  current  policy  is  to 
allow  one  inventory  site  per  200  hectares 
(500  acres).  For  larger  installations  this 
may  represent  an  unmanageable  number  of 
sites.  Therefore,  the  maximum  number  of 
sample  sites  is  limited  to  200.  These  sites 
are  randomly  allocated  to  the  polygons  in  a 
stratified  fashion  based  on  the  percentage  of 
the  installation  occupied  by  each 
landcover/ soil  category.  This  process 
ensures  proportional  representation  of  all 
landcover  types  and  soil  series.  In  addition, 
it  allows  the  spectrally  recognized  landcover 
categories  to  be  subdivided  by  soil  series  if 
field  data  indicate  that  more  than  one  vege¬ 
tation  community  occurs  within  a  given 
landcover  categoiy. 

Field  crew  leaders  are  provided  with 
clear  Mylar  plastic  overlays  which 
correspond  to  US  Geologic  Survey  quadran¬ 
gle  maps.  The  overlays  are  printed  with  all 
polygons  of  sufficient  size  to  be  sampled. 
The  color  scheme  for  the  polygons  is  based 
on  the  landcover  categories.  Polygons 
selected  for  inventory  by  the  randomization 
process  are  labeled  with  icons.  Soil  series 
delineations  are  outlined  in  black.  It.  is  the 
responsibility  of  the  field  crews  to  identify 
and  inventory  the  areas  represented  by  the 
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selected  polygons.  Once  a  given  polygon  is 
found,  the  field  crew  establishes  a  per¬ 
manently  marked  vegetation  transect  that 
can  be  relocated  and  monitored  in  future 
yearn  to  evaluate  trends  of  declining  or 
improving  land  condition.  In  the  event  that 
any  given  polygon  is  inaccessible  or 
unidentifiable  in  the  field,  the  crew  leader 
must  select  the  next  nearest  polygon  of  the 
same  iandcover  color  code  and  soil  series. 


Conclusion 

This  procedure  for  land  condition 
inventory  site  selection  is  currently  being 
implemented  at  15  m<\jor  US  Army  training 
installations  in  the  United  States  and  West 
Germany.  Future  improvements  in  the  pro¬ 
cedure  will  depend  largely  on  advancements 
in  the  field  of  remote  sensing  and  image 
interpretation. 
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ABSTRACT 

An  example  of  designing  a  sampling  scheme  using  GRASS  GIS  technol¬ 
ogy  will  be  presented.  Topics  to  be  discussed  include  the  use  of  GRASS  tools 
in  defining  and  redefining  the  population  to  be  sampled  and  the  need  to  clearly 
define  the  hypothesis  being  tested,  as  well  as  the  benefits  GIS  technology  can 
provide  toward  sampling  design. 


The  Air  Quality  Division  of  the 
National  Park  Service  was  requested  by  the 
Pacific  Northwest  Regional  Office  to  estab¬ 
lish  an  baseline  of  elemental  composition  of 
vegetation  and  soils  in  North  Cascades 
National  Paris  Complex.  This  was  to  deter¬ 
mine  whether  anthropogenic  pollutants  are 
being  deposited  in  the  park’s  ecosystems. 
The  sampling  process  was  to  include  analysis 
of  subalpine  fir,  lichens,  mosses,  and  soils. 
A  sampling  plan  was  to  be  developed  using 
the  existing  geographic  information  system 
(GIS)  data  base  for  North  Cascades  National 
Park  Complex.  This  data  base  includes  a 
vegetation/ cover  type  theme  (Agee  et  al. 
1985,  Root  et  al.  1985),  and  elevation, 
slope,  and  aspect  derived  from  Defense 
Mapping  Agency  (DMA)  1:250000  scale 
data 

Working  with  a  member  of  the  Air 
Quality  Division  staff  and  the  team  con¬ 
tracted  to  collect  the  field  data,  the  sampling 
population  was  initially  defined  to  be  open 
canopy  subalpine  fir  on  south,  southwest, 
and  west  facing  slopes  and  within  the  park 
complex  boundary.  These  aspects  were 
chosen  based  on  the  assumption  that  the 
large  air  masses  were  flowing  into  the  park 
from  the  southwest,  and  would  appear  in 
vegetation  on  southwest  facing  slopes  earlier 
and  more  significantly  than  on  other  slopes. 


Open  canopy  was  important  because  pollu¬ 
tants  would  presumably  impact  open  canopy 
vegetation  more  easily  than  closed  canopy 
vegetation. 

The  analysis  to  define  areas  fitting 
these  restrictions  was  relatively  simple  using 
the  GRASS  GIS  package.  The  vegetation 
data  was  masked  to  include  only  the  area 
within  the  National  Park  Complex  boundary. 
This  layer  was  created  as  a  cell  file  through 
Gmapcalc.  This  theme  was  then  reclassed 
to  include  only  open  canopy  subalpine  fir 
and  masked  with  south,  southwest,  and  west 
facing  slopes  thus  establishing  the  sampling 
population,  or  so  we  thought. 

The  next  question  was  how  to  best 
sample  this  population.  One  of  the  criteria 
was  that  the  sampling  locations  needed  to  be 
spread  throughout  the  park  complex  to 
establish  a  parkwide  baseline.  It  was 
thought  that  a  total  number  of  sites  between 
15  and  25  could  be  successfully  sampled 
within  a  single  field  season. 

Three  possible  strategies  were  pro¬ 
posed  for  choosing  sampling  locations.  Sim¬ 
ple  random  sampling,  not  chosen  since  it 
would  not  be  likely  to  generate  sampling 
locations  spread  throughout  the  park  com¬ 
plex.  The  second  proposed  strategy  was 
equal  area  /  random  sampling  meaning  split¬ 
ting  the  park  complex  into  regions  contain- 
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ing  equal  park  area  from  which  random  sites 
could  be  chosen.  This  method  was  not 
chosen  since  it  would  change  the  likelihood 
of  any  given  cell  being  chosen  as  a  sampling 
site.  Areas  with  more  sampling  population 
cells  would  reduce  the  chance  of  any  given 
one  being  chosen  for  sampling  and  areas 
with  fewer  sampling  population  cells  would 
have  an  increased  likelihood  of  any  given 
one>  being  chosen  for  sampling.  The  final 
prrqxised  sampling  method  of  equal  popula¬ 
tion  random  sampling  seemed  die  most 
appropriate.  It  consisted  of  splitting  the 
park  complex  into  regions  containing  equal 
numbers  of  sampling  population  cells  and 
then  sampling  randomly  within  each  region. 
This  method  provided  a  means  of  spreading 
the  sampling  site's  throughout  the  park  com¬ 
plex  without  making  any  given  cell  any 
more  or  less  likely  to  be  chosen  for  ,-nin- 
pling. 

A  report  was  run  to  determine  the 
totiil  number  of  sampling  population  cells, 
and  it  was  decider!  to  split  the;  park  complex 
into  25  regions  within  which  a  random  sam¬ 
pling  site  would  be  selected.  Initially  tli« 
park  was  split  into  5  regions  running 
east/west  each  containing  one  fifth  of  the 
sampling  population.  This  was  accomplished 
by  changing  the  window,  then  running  a 
report  to  determine  tire  number  of  sampling 
population  cells  within  the  window,  and  by 
trial  and  error,  locating  the  window  which 
would  contain  as  close  to  one  fifth  the  sam¬ 
pling  population  as  possible.  Again  by  fa-ail 
and  error,  each  easbwest  region  was  split 
into  5  smaller  regions  each  containing  one 
twenty-fifth  of  the  total  sampling  population. 
Windowing  in  on  each  of  the  25  rectangular 
regions,  a  single  sampling  point  was  ran¬ 
domly  selected  by  generating  random  utin 
coordinate  pairs  through  a  computer  driven 
random  number  generator,  and  using  the 
first  location  which  fell  within  a  sampling 
{xrpulation  cell.  This  process  was  tedious, 
and  required  the  generation  of  hundreds  of 
coordinate  pairs  before  locating  one  which 
fell  within  a  sampling  population  cell. 

The  sites  were  plotted  and  the  field 
crew  visited  the  park,  at  which  time  the  park 
staff  reviewed  the  procedure  and  a  few  of 
the  selected  points  were  sampled.  The  accu¬ 
racy  of  the  sample  locations  being  open 
canopy  subalpine  fir  was  low  within  the  first 


few  sample  points  visited,  and  the  terrain 
was  steep  enough  to  make  field  work  virtu¬ 
ally  impossible  in  some  locations.  In  addi¬ 
tion,  the  park  staff  requested  that  the  sam¬ 
pling  procedure  be  changed  to  allow  for 
comparisons  between  watersheds.  Their 
experience  led  them  to  believe  the  air  was 
flowing  in  different  patterns  within  different 
watershed  regions  of  the  park,  the  largest 
difference  being  between  the  areas  east  and 
west  of  the  continental  divide. 

Seven  watersheds  (G.  Larson  et  al., 
Oregon  Stale  Univ.,  Draft)  were  delineated 
on  a  park  topographic  map  and  then  digi¬ 
tized  and  entered  into  the  North  Cascades 
data  base.  These  then  became  the  regions 
wi  tii  in  which  sampling  was  done  and 
between  which  the  sampling  results  could  be 
compared. 

The  population  to  be  sampled  was 
redefined  to  ameliorate  the  problems 
encountered  in  the  field.  It  was 
hypo the sized  that  a  given  cell  was  more 
likely  to  be  classified  correctiy  as  subalpine 
hr  if  it  was  not  a  single  cell,  but  was  within 
a  iarge  "polygon"  of  subalpine  fir  cells.  A 
requirement  was  established  that  all  stands 
of  open  canopy  subalpine  fir  be  at  least  19 
acres  in  size  to  be  included  in  the  sampling 
population.  A  cell  file  with  these  stands  was 
generated  by  running  Gclump  on  open 
canopy  subalpine  fir,  then  generating  a 
report  on  tins  new  layer,  and  manually 
choosing  and  reclassing  only  those  clumps 
which  were  at  least  19  acres  in  size.  South, 
southwest,  and  west  slopes  were  then  used 
as  a  mask,  and  a  new  layer  of  open  canopy 
subalpine  fir  on  south,  southwest  or  west 
facing  slopes  was  developed.  The  problem 
of  field  work  on  extremely  steep  slopes  was 
ameliorated  by  masking  on  slopes  less  than 
65%. 

It  was  requested  by  the  field  crew  that 
at  least  10  random  sites  within  each 
watershed  be  generated,  so  that  if  a  site  was 
not  correctly  identified  as  subalpine  fir,  a 
new  sampling  location  could  be  easily 
identified  while  in  the  field.  At  this  time 
GRASS3.beta  had  been  compiled  on  the 
computer  being  used,  so  the  random  sample 
locations  within  each  watershed  were  gen¬ 
erated  through  tiie  new  module  random. 
These  sites  were  plotted  for  the  field  sam¬ 
pling  work. 
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The  use  of  GI3  technology  greatly 
enhanced  and  streamlined  the  creation  of  a 
sampling  design.  The  sampling  strategy  was 
changed  in  mid-project  and  a  new  sampling 
population  was  defined.  This  would  have 
been  more  complex  or  perhaps  even  impos¬ 
sible  without  the  use  of  a  GIS.  However 
much  work  could  have  been  avoided  if  the 
question  to  be  answered  by  this  study,  had 
been  clearly  defined  earlier  in  the  project. 
Specifically,  are  the  comparisons  of  results 
to  be  done  on  an  east-west  and  north-south 
basis,  or  between  geographically  defined 
regions  such  as  watersheds.  Through  the 
use  of  GRASS  GIS,  the  population  to  be 
sampled  was  readily  defined  and  redefined 
within  a  short  rime  frame,  without  a  GIS, 
the  same  questions  could  not  have  been 
easily  answered. 
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ABSTRACT 

Archeological  site  data,  like  geographical  data,  consist  of  observations  of 
the  spatial  properties  of  various  phenomena,  that,  can  he  manipulated  and 
transformed  to  gain  insights  into  problems  of  a  multivariate  nature.  While, 
archeological  site  analysis  operates  on  a  much  smaller  geographic  scale  than 
most  GIS-based  studies,  the  multi-faceted  complexity  of  a  large  excavated  site 
containing  thousands  of  artifacts,  structural  n  oains,  and  activity  loci  can  pose 
as  great  a  challenge  in  data  management,  analysis,  and  interpretation  as  any 
regional  study.  By  applying  a  GIS  system  in  concert  with  a  relational  database 
such  as  INFORMIX  together  with  an  exploratory  data  analysis  system  such  as 
die  vS  interactive  statistical  environment,  this  analytic  task  can  be  much 
improved  over  traditional  archeological  intra-site  analysis  procedures. 


Background 

Over  the  past  two  years  the  Arkansas 
Archeological  Survey  lAAS),  with  the 
cooperation  of  the  U.S.  Army  Construction 
Engineering  Research  Lab  iCERL),  has 
engaged  in  developing  GRASS-GIS  applica¬ 
tions  in  the  assessment  of  site  variability  at 
Ft.  Hood,  Texas.  Our  most  recent  efforts  to 
erroloy  GRASS  in  archeological  analysis 
focuses  in  on  the  individual  site  as  the  basic 
unit  of  study.  This  area  of  GRASS  archeo¬ 
logical  applications  at  the  AAS  is  only  in  its 
iniual  developmental  stage  and  more  work 
remains  to  be  done  before  we  can  report 
fully  on  the  utility  of  GRASS  for  this  type 
of  analysis.  This  paper  discusses  some  of 
the  characteristics  of  archeological  site  data 
to  show  how  an  approach  that  combines  a 
relational  database  management  system,  a 
GIS,  and  a  statistical  system  for  exploratory 
data  analysis  can  be  implemented  to 
improve  the  efficiency  and  flexibility  of 
intra-site  analysis. 


Conventional  Archeological  Intra-Site 
Analysis 

The  archeologist  seeks  to  reconstruct 
past  lifeways  by  uncovering  and  bringing 
order  to  the  distributions  of  tools,  tool  mak¬ 
ing  debris,  cooking  hearths,  trash  pits, 
house  support  postholes,  stockade  lines, 
burials,  food  remains,  and  other  deposits. 
Typically  the  archeologist  has  a  number  of 
aspects  of  site  data  to  explore  and  multiple 
questions  to  answer.  Some  basic  questions 
might  relate  to  the  vertical  and  horizontal 
locations  and  associations  of  well-datable 
diagnostic  artifacts  that  can  be  used  to  deter¬ 
mine  the  age  and  cultural  affiliation  of  levels 
of  the  site  or  the  existence  of  particular  tool 
kits  as  inferred  from  the  covariation  over 
space  of  sets  of  artifacts.  Beyond  the  stan¬ 
dard  goals  of  placing  the  site  within  a  gen¬ 
eral  temporal  and  cultural  context,  the 
archeologist  might  also  want  to  explore  the 
spatial  aspects  of  site  development  in  terms 
of  the  partition  of  the  site  into  discrete  use- 
areas  corresponding  to  site  occupation 
episodes,  family  household  locations,  task- 
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specific  activity  loci,  group  or  public  use- 
areas,  family  and  village  waste  disposal 
areas,  and  ceremonial  areas. 

These  levels  of  archeological  pattern 
recognition  must  be  inferred  from  basic 
units  of  artifact  data  recovery.  This  is 
accomplished  through  careful  excavation  of 
the  deposits  with  very  precise  control  over 
the  provenience  or  vertical  and  horizontal 
location  of  archeological  samples.  Fre¬ 
quently  there  are  two  closely  related  com¬ 
ponents  to  a  site  occupation.  The  fust  is  fhe 
consists  of  the  narrow  zone  of  archeological 
debris  perhaps  10  to  30  cm  thick  extending 
horizontally  across  the  site  which  encom¬ 
passes  the  original  living  surface  and  con¬ 
tains  most  of  the  site  debris.  Such  debris 
may  include  dusters  of  tools  and  pottery, 
lost  or  discarded  artifacts,  the  waste  debris 
•Tom  stone  tool  manufacture,  and  bits  of 
noil,  animal  bone,  and  carbonized  plant 
remains  discarded  as  refuse  The  second 
part  of  a  site  occupation  includes  the  pits, 
house  support  postholes,  stockade  lines, 
Durials,  and  hearths  commonly  referred  to 
as  features  that  were  dug  by  the  inhabitants 
of  the  site  through  the  occupation  level  into 
the  subsoil  below.  Data  from  the  occupa¬ 
tion  surface  are  recovered  through  excava¬ 
tion  of  square  sample  units  laid  out  across 
the  site  in  a  grid  fashion  while  features  usu¬ 
ally  are  excavated  as  discrete  units. 
Features  and  sampling  units  and  the  particu¬ 
lar  vertical  levels  in  which  each  were  exca¬ 
vated  represent  proveniences  that  constitute 
the  fundamental  units  of  site  analysis. 

After  laboratory  processing,  conven¬ 
tional  site  analysis  begins  by  examining  the 
distribution  of  classes  of  artifacts  such  as 
pottery,  lithic  tools,  lithic  waste  material, 
bone,  plant  remains  and  other  samples  for 
the  site  as  a  whole  and  for  each  of  the 
feature  and  test  unit  proveniences.  At  some 
point  in  the  analysis,  the  archeologist  begins 
to  focus  in  on  the  relationships  between 
pairs  or  sets  of  multiple  artifact  classes  that 
are  associated  with  an  activity  or  some  other 
behavior  that  took  place  on  the  site  as 
inferred  from  their  covariation  across 
features  and  test  units  and  between  different 
horizontal  zones  of  the  site.  For  lack  of  any 
other  means,  site  data  are  often  analyzed  in 
a  rote  fashion  to  look  for  significant  statisti¬ 
cal  trends  in  the  univariate,  bivariate,  and 


multivariate  associations  of  tool  sets  and 
artifact  classes.  In  relying  on  cumbersome 
time-consuming  batch  programs,  there  is 
often  little  chance  for  multiple  iterations  to 
explore  alternative  ways  of  expressing  the 
data  and  refining  results. 

To  explore  intra-site  patterns,  detailed 
site  plans,  consisting  of  meticulously  hand- 
drawn  maps  of  features,  artifacts,  and  test 
units,  are  then  manually  or  mentally  over¬ 
laid  to  obtain  a  sense  of  the  composition  of 
the  site  with  respect  to  the  dozens  of  single, 
bivariate,  and  multivariate  dimensions  of  the 
data.  This  sometimes  includes  the  expres¬ 
sion  of  raw  cr  transformed  data  to  assess 
spatial  patterns  in  the  distribution  of 
artifacts  using  choroplethic  mapping  tech¬ 
niques.  Because  the  techniques  to  accom¬ 
plish  these  tasks  are  not  well  integrated,  the 
process  of  setting  up  and  running  programs 
for  intra-site  spatial  analysis  consumes  a 
large  amount  energy  that  could  be  better 
spent  in  the  actual  mental  processes  of  site 
analysis. 

A  Comprehensive  System  for  Intra-Site 
Analysis 

What  lacking  in  the  conventional 
approach  to  site  analysis  is  a  comprehensive 
means  of  efficiently  storing,  displaying, 
combining,  and  manipulating  artifact  data  in 
an  interactive  fashion  to  explore  data  and 
build  a  series  of  new  site  maps  that  derive 
from  the  resuiting  higher  levels  of  under¬ 
standing  of  the  multidimensional  aspects  of 
the  data  attained  at  each  step  of  the  analysis. 
What  is  needed,  in  addition  to  access  to  a 
GIS  like  GRASS,  is  relational  database 
management  system  to  serve  as  a  means  of 
retrieving  basic  descriptive  and  locational 
information  on  artifacts  referenced  to  each 
feature  and  sample  unit  provenience  and 
linkage  between  the  GIS  and  a  compatible 
interactive  exploratory  data  analysis  (EDA) 
system.  Fortunately,  the  components 
needed  to  build  such  a  system  are  available 
now. 

The  first  component,  an  efficient  data¬ 
base,  is  met  at  the  AAS  with  an  INFORMIX 
relational  database  called  DELOS  developed 
by  the  Survey  to  access  site  level  archeologi¬ 
cal  data.  DELOS  is  designed  to  afford  flexi¬ 
ble  processing  of  data  about  archeological 
materials  and  their  spatial  context  by  linking 
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provenience  infonnation  concerning  the 
vertical  and  horizontal  locaLion  of  ail  artifact 
with  descriptive  observations  about  the  mor¬ 
phology-  and  cultural  context  of  the  artifact. 
The  DKLOS  system  for  ordering  artifacts  is 
arranged  in  a  hierarchical!  framework  to 
allow  for  varying  levels  of  specificity  in  the 
classification  of  artifacts.  For  example,  one 
could  access  the  locations,  counts,  and 
weights  of  all  pottery  from  a  site  or  pottery 
of  a  ceitain  design  ;uid  cultural  affiliation,  or 
only  tiie  counts  ol"  rim  fragments  for  a  a  r 
tain  pottery  type  or  tile  vessel  diameters  tor 
rims  In  addition,  these  potu  ry  attributes 
could  be  accessed  for  any  or  all  discrete 
excavation  units  and  vertical  levels  within 
units  or  for  various  pits,  postmolds,  and 
burials. 

Two  of  tiie  components  of  tins  site 
analysis  system,  a  GIS  and  an  EDA  are 
alreaiv  well  integrated  in  GRASS  iCEKI. 
198s  .  GRASS,  tiie  Geographical  Resources 
Analysis  Support  System,  is  a  comprehen¬ 
sive  Geographical  infonnation  System  GIS 
developed  for  Army  installations  by  tiie  U.S. 
Army  Gonstniction  Engineering  Research 
Ixiboratory  CERL' .  GRASS  is  an 
integrated  set  of  tools  to  manage  land 
resources  by  providing  means  of  inputting, 
storing,  and  manipulating  data  which  are 
stored  in  maplayers  consisting  of  spatially 
discrete  cells  across  the  region  of  interest. 
GRAS'  can  store  and  process  infonnation  in 
tenns  of  a  vectors  t clumps  of  cells)  or  as 
cooniinate  point  data  (single  cells).  Many 
useful  tools  for  intra-site  analysis  are  avail¬ 
able  in  GRASS  such  as  mapping  programs, 
nearest  neighbor  analysis,  proximity 
analysis,  cost-surface  studies,  coincidence 
and  chi  square  tables,  and  many  other 
boolean,  mathematic,  and  algebraic  func¬ 
tions  that  operate  on  mapsets. 

The  EDA  component  is  met  by  "S',  an 
interactive  environment  for  data  screening, 
analysis,  and  graphical  display  that  runs 
under  the  UNIX  operating  system  of  Bell 
1  *abo rate ries  (Becker  and  Chambers  1984). 
EDA  is  an  inductive  approach  to  searching 
for  patterning  in  a  dataset  with  tiie  goal  of 
of  gaining  insights  into  the  nature  of  tiie 
data’s  total  structure,  particularly  tiie  unanti¬ 
cipated  relationships  that  may  occur.  EDA 
involves  iterative,  stepwise  examination  ,„'d 
visiicil  ins|x*ction  of  the  many  alternative 


representations  of  the  data  and  utilizes 
graphic  representations  such  as  three- 
dimensional  plot  rotations  of  multivariate 
relationships  to  bring  the  brain’s  full  visual 
processing  capabilities  into  tiie  gestalt  of  pat¬ 
tern  recognition.  S  can  also  be  used  to 
setup  deductive  analysis  by  using  the  EDA 
capabilities  as  an  entry  level  step  in  a  multis¬ 
tage  investigation  where  the  relevant  rela¬ 
tionships  are  first  assessed  to  explore  tiie 
complex  multidimensionality  of  the  data 
prior  In  hypothesis  formulation  ( Gan-  1985) . 

hi  addition  to  the  analytic  tools  pro¬ 
vided  within  GRASS,  GRASS  is  setup  to 
transport  infonnation  from  data!  aye  is  to  S 
via  die  GRASS  to  S  module,  and  the  S  sys¬ 
tem  is  well  setup  for  other  sorts  of  analytic 
techniques  that  may  be  desirable  in  site 
analysis.  Thus,  if  tiie  rnapset  categories  are 
features,  sample  units,  and  surface  collec¬ 
tion  grids  and  the  mapsets  are  all  a-tifact 
classes  recovered  during  the  excavation, 
GRASS  acts  as  a  component  in  a  database 
management  system  for  setting  up  EDA  in 
6.  The  AAS  has  developed  modules  in  S 
that  make  available,  in  a  menu  form,  mac¬ 
ros  for  univariate,  bivariate,  and  multivari¬ 
ate  analysis  of  datasets  that  have  been  tran¬ 
sported  from  GRASS.  The  modules  will 
allow  access  to  S  statistical  options  such  as 
box  plots,  histograms,  bivariate  plots,  regres¬ 
sion  analysis,  three-dimensional  spin  of  data 
swarms,  cluster  analysis,  principal  com¬ 
ponents  analysis,  discriminant  function 
analysis,  multidimensional  analysis,  and 
many  others.  There  is  also  the  capability  of 
routing  output  from  analysis  in  S  back  into 
GRASS  as  a  new  maplayer  to  be  displayed 
and  manipulated  using  GIS  tools. 

Setting  up  Site  Data  for  GRASS  and  S 
Analysis 

The  AAS  is  in  the  process  of  analyzing 
and  loading  site  data  into  GRASS  for  the 
Hardman  Site  (3C1418>  located  in  Clark 
County.  Arkansas  recently  excavated  by  the 
AAS  for  the  Arkansas  Highway  Transporta¬ 
tion  Department.  Hardman  is  a  prehistoric 
Caddo  Indian  habitation  and  salt  processing 
site,  dating  between  1400  to  about  1600 
A.D.  Excavations  at  Hardman  recovered 
over  900  features  identified  as  support-posts 
for  houses,  screens,  and  enclosures;  refuse 
pits;  burials;  hearths;  and  thousands  of 
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artifacts  of  stone,  bone,  and  shell;  frag¬ 
mented  and  whole  ceramic  cooking,  storage, 
and  salt  evaporation  vessels;  plant  and 
animal  food  remains;  and  chro  no  metric 
samples  that  will  be  used  to  date  areas  or 
levels  at  the  site. 

The  excavation  sample  units  of  the 
occupation  zone  include  a  dozen  2  by  2 
meter  units  and  fifty-five  1  meter  by  50  cen¬ 
timeter  column  samples.  These  units  are 
being  individually  digitized  as  vector 
maplayers  from  records  made  in  the  field. 
Each  unit  vector  has  an  identification  label 
that  corresponds  to  the  field  specimen 
number  assigned  all  artifacts  recovered 
within  each  level  of  each  unit  of  the  occupa¬ 
tion  zone.  This  maplayer  of  excavation 
units  will  be  loaded  with  counts  and  weights 
of  particular  artifact  types,  bone,  plant, 
•emains,  etc.,  from  the  DELOS  database 
iind  new  seperate  maplayers  will  be  created 
for  ea'h  class  of  archeological  material. 
dTiese  datalayers  will  then  be  accessible  to 
GRASS  tools  such  as  neighbors,  Ginfer,  and 
Gmapcalc  to  extrapolate  patterns  in  the  den¬ 
sity  distribution  of  artifacts.  Datalayers  can 
also  be  combined  when  appropriate  with  the 
overlay  tools  in  GRASS  to  provide  a  view  of 
patterns  of  multiple  artifact  distributions  and 
evaluated  with  the  coincidence  tools  to 
assess  the  association  of  pairs  of  artifact 
classes. 

The  features  (hearths,  burials,  pits, 
and  postholeru  are  being  digitized  as  vectors 
or  as  coordinate  points  from  site  maps 
prepared  from  drawings  and  instrument 
readings  made  in  the  field.  One  maplayer 
will  be  made  for  each  of  the  feature  classes 
to  permit  flexibility  in  later  segregation  or 
overlay.  The  vectors  are  of  a  variety  of 
shapes  consisting  of  circles,  ovals,  and  irreg¬ 
ular  amoeboid- like  features  which  are  being 
digitized  using  the  stream  mode.  The 
majority  of  the  postholes  are  being  loaded  as 
points  which  can  be  displayed  with  icons 
designed  to  approximate  the  circular  shape 
and  proportional  diameter  of  the  original 
posthole  so  that  a  realistic  map  of  the  site 
can  be  displayed.  Like  the  excavation  units 
artifact  data  from  DELOS  are  being  loaded 
into  each  feature  vector  to  create  many 
datalayers  that  can  be  analyzed  with  GRASS 
and  S  tools  in  a  number  of  permutations  of 
feature  type  and  artifact  class. 


Since  the  vast  number  of  postholes 
makes  recognition  of  circular  house  pat¬ 
terns,  enclosures,  and  other  sets  of  related 
features  difficult,  the  postholes  maplayer  will 
be  subsetted  to  remove  the  noise  created  by 
multiple  and  overlapping  occupation 
episodes.  As  we  leam  more  about  the  site 
based  on  the  archeological  content  of 
features,  a  series  of  maps  will  be  generated 
to  represent  our  understanding  of  the  pat¬ 
terns  and  associations  of  pits,  burials, 
postholes,  and  hearths  and  their  affiliation 
with  datable  episodes  of  site  use.  Multivari¬ 
ate  analysis  of  the  artifact  content  of  the 
occupation  level  and  the  features  should 
help  us  to  also  obtain  details  about  the  spa¬ 
tial  structure  of  the  site  with  respect  to  the 
positions  of  activity  use-areas  which  can  also 
be-  displayed  with  the  other  site  data  to  build 
a  picture  of  the  site  for  the  various  prehis¬ 
toric  oecrpation  episodes. 

The  use  of  GRASS  in  combination 
with  a  relational  database  management  sys¬ 
tem  like  DELOS  and  an  interactive  EDA 
such  as  S  can  go  far  in  providing  the  tools 
necessary  for  fleshing  out  the  multidimen¬ 
sional  nature  of  site  development  and  past 
life  ways.  A  detailed  evaluation  of  the 
implementation  of  GRASS  in  the  Hardman 
intra-site  analysis  will  be  reported  later  this 
year. 
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ABSIJiACT 

The  Arkansas  Arched*  gical  Survey  is  currently  preparing  an  overview  of 
the  cultural  resources  found  in  (lie  U.S.  Anr»y  Corps  of  Engineers' 
>Southwestem  Division.  This  paper  outlines  tlie  processes  involved  in 
representing  the  spatially  oriented  attributes  of  the  eight-state  region  using 
GRASS  and  die  cartographic  technique  of  choropleth  mapping.  In  particular, 
the  issues  of  data  collection,  standardization,  , 'asafieation,  symbolization,  and 
map  production  are-  discussed  in  terms  of  cartograpluc  theory  and  GRASS  appli¬ 
cations. 


Over  tlie  past  several  years,  the  Arkan¬ 
sas  Archeological  Survey  has  been  preparing 
an  overview  of  tlie  cultural  resources  found 
in  the  U.S.  Army  Corps  of  Engineers' 
Southwestern  Division.  Among  other  tasks, 
the  project  involves  the  identification  of  cul¬ 
tural  features  found  in  the  study  area,  and 
will  result  in  a  number  of  recommendations 
concerning  resource  management.  These 
recommendations  will  lie  based,  in  part,  on 
locational  analysis  made  possible  through 
the  development  of  a  database  and 
corresponding  GRASS  data  layers. 

The  study  area  encompasses  almost  20 
percent  of  the  continental  United  States  and 
is  comprised  of  more  than  600  counties  in 
Arkansas,  Louisiana.  Texas,  Oklahoma 
New  Mexico,  and  parts  of  Missouri,  Kansas, 
and  Colorado.  The  corresponding  database 
for  the  Southwestern  Division  contains  a 
number  of  individual  data  themes,  ranging 
from  various  attributes  of  archeological 
interest  to  demographic  information  such  as 
population  density  and  change  over  time. 
Much  of  the  available  information  was 
recorded  in  the  form  of  county  totals. 

Data  collected  by  statistical  areas  such 
as  counties  is  often  represented  using  the 


cartographic  technique  of  choropleth  map¬ 
ping.  From  the  Greek  words,  "chores" 
meaning  place,  and  "plethos"  meaning  mag¬ 
nitude,  the  term  "choropleth"  denotes  a 
specific  type  of  representation  in  which 
quantitative  thematic  maps  are  used  to  sym¬ 
bolize  tlie  magnitude  of  ordinal  level  data 
within  the  boundaries  of  unit  areas  (Robin¬ 
son  et  al.,  1984). 

The  extensive  use  of  choropleth  maps 
may  be  due,  in  large  part,  to  the  efficiency 
with  which  they  communicate  geographic 
information,  and  the  relative  ease  with 
which  they  can  be  produced  (Anderson  and 
Child,  1987).  There  are,  however,  several 
fundamental  cartographic  principles  that 
should  be  considered  in  the  design  process  if 
these  maps  are  to  be  effective  in  terms  of 
graphic  communication.  In  particular, 
choropleth  mapping  is  dependent  on  data 
collected  by  statistical  or  administrative 
areas  such  as  states,  counties,  or  census 
tracts.  Because  these  units  are  often  of 
unequal  size,  the  data  to  be  used  is  generally- 
standardized  such  that  it  takes  the  form  of 
some  type  of  ratio  such  as  densities  or  per¬ 
centages.  After  the  dita  is  standardized,  the 
data  elements  are  typically  grouped  into  four 
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to  seven  classes  each  of  which  is  assigned  a 
representative  color  or  pattern.  Using  this 
technique,  each  area  on  a  map  is  assigned 
the  appropriate  symbolization  according  to 
the  data  range  it  fits  into.  Finally,  map  ele¬ 
ments  such  as  the  title,  scale,  legend,  and 
data  source  arc  added  to  complete  the  carto¬ 
graphic  product. 

Data  Collection  The  initial  require¬ 
ment  for  the  mapping  aspect  of 
Southwestern  Division  Overview  was  the 
collection  of  quality  information.  The  data 
used  in  the  project  comes  from  a  variety  of 
sources  including  the  U.S.  Census  of  Popu¬ 
lation,  and  archeological  inventories  for  each 
of  the  six  study  units.  Data  for  each  attri¬ 
bute  to  be  mapped  was  entered  into  a  data¬ 
base  according  to  county  o;  county 
equivalent.  So,  the  first  data  field  consisted 
of  the  609  county  names  sorted  alphaben- 
mJ  iv  The  next  field  contained  earn 
county’s  identification  number.  Phis 
number  vae  also  encoded  into  the 
corresponding  county  area  on  the  base  map 
in  GRASS  so  that  data  values  could  be 
keyed  to  their  locational  counterparts  The 
ntx.  two  fields  consisted  of  state  and  study 
unit  affiliation.  Then,  a  field  for  each  of  the 
variables  to  be  mapped  was  established,  and 
die  appropriate  values  for  each  county  were 
entered. 

Data  Standardization  Certain  data 
fields,  such  as  "county  area  in  square  miles" 
and  "population  by  county",  were  added  to 
the  data  base  for  purposes  of  standardiza¬ 
tion.  As  previously  mentioned,  data  in  the 
form  of  absolute,  or  raw,  numbers  alone  are 
not  ordinarily  used  in  choropleth  mapping 
-  Robinson  et  al.,  1984).  Absolute  numbers 
are  typically  standardized  so  that  the  data  is 
represented  either  by  ratios  involving  area 
such  as  densities,  or  ratios  independent  of 
area  such  as  percentages  or  proportions. 
The  mason  for  this  is  that  most  choropleth 
maps  contain  areas  which  are  unequal  in 
size.  F  r  example,  Los  Alamos  County,  a 
very  small  county  in  north-central  New 
Mexico  and  its  neighboring  county,  Santa 
Fe.  have  a  similar  number  of  archeological 
sites.  However,  to  show  them  in  the  same 
class  would  be  a  misrepresentation  due  to 
fact  that  Santa  Fe  County  is  more  than  17 
times  larger  than  Los  Alamos  County.  To 
comet  for  this,  archeological  sites  in  each  of 


the  two  counties  were  standardized  by 
county  area  so  that  the  finished  map 
represented  archeological  sites  per  square 
mile.  An  example  of  standardization 
independent  of  area,  on  the  other  hand, 
might  be  a  choroplethic  representation  of 
population  crange  throu^i  time  in  which 
change  for  each  county  is  shown  as  a  per¬ 
centage  so  that  the  unequal  size  of  the 
counties  is  not  a  factor. 

Data  Classification  After  the 
Southwestern  Division  database  was  in 
place,  die  next  step  was  to  establish  data 
categories  for  each  attribute  by  grouping 
similar  data  elements  into  classes.  The  pur¬ 
pose  for  classing  the  daia  is  to  generalize, 
and  them  by  simplify  and  enhance  the  recog¬ 
nition  of  the  geographic  patterns.  In  order 
to  maximize  classing  accuracy,  areas  which 
are  quantitatively  similar  should  be  grouped 
together  and  represented  by  the  same  sym¬ 
bol  However,  because  of  the  existence  of  a 
variety  of  classing  procedures,  several 
different  map  distributions  car.  be  generated 
u.-ing  a  angie  data  se*  This  situation  poses 
a  problem  to  cartographers  concerning  which 
classing  method,  or  algorithm,  to  use  with 
any  given  data  set.  While  certain  classing 
methods  produce  more  accurate  results  with 
certain  data  distributions,  some  research  has 
shown  that  the  classing  method  most  likely 
to  produce  accurate  and  reliable  results  with 
any  distribution  is  the  optimization  pro¬ 
cedure  first  proposed  by  Jenks  and  Caspall 
in  1971  (Smith,  1986).  Optimization  class¬ 
ing  is  an  iterative  process  which  establishes 
class  intervals  by  minimizing  variation 
within  classes  and  maximizing  variation 
between  classes. 

In  addition  to  accurate  classification, 
proper  legend  design  can  also  enhance  the 
effectiveness  of  choropleth  map  communica¬ 
tion  The  legend  should  contain  the  actual 
class  limits  without  reporting  values  which 
do  not  occur  in  the  data  set.  The  result  is  to 
narrow  the  readers  estimate  of  the  actual 
value  of  any  area  belonging  to  each  category 
( Dent,  1985) . 

Data  Symbolization  Conceptually,  by 
using  area  symbols  with  quantitative  data,  a 
statistical  surface,  or  z- value,  is  implied.  In 
choropleth  mapping  each  statistical  area  is 
symbolized  to  represent  the  vertical  height 
of  its  data  value  (Dent,  1985).  This  princi- 
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pie  can  be  demonstrated  in  GRASS  by 
assigning  a  vertical  exaggeration  to  any 
choropU-thic  data  layer,  and  then  viewing 
tin-  result  from  an  oblique  angle  using  the 
GRASS  module  "d Ad".  A  choropleth  map. 
in  other  won  Is,  is  a  planimetric  representa- 
tion  of  a  "stepp'd"  slabs  ,cal  surface  in  tiiat 
tile  data  used  is  discrete  rather  than  continu¬ 
ous.  and  distributions  are  co’'tmiled  by  px) i ■■ 
ideal  or  administrative  subdivisions. 

file  primary  objective  m  carto  irrupt  no 
symbolization  is  to  preset \  c  clarity  and 
avoid  visual  confusion  or  ambiguity  i -Jenhs 
and  Kilos.  19bl'.  Ordinarily.  si  net  <■  Ucm 
pietli  maps  art-  intended  to  delineate  amal 
differences  in  magnitude.  class  svmboiiza- 
di'ii  should  bt-  designed  sucli  mat  the  reader 
can  r’liutivviy  disc'-ra  tiie  hierarchic  organi 
zation  of  U.e  map  categories.  In  otlier 
word.-.  liiv  raider  sliould  be  alile  to  de-er¬ 
mine  the  hierarchy  even  without  a  iigend. 
Random  or  impn>|xr  symbol  selection,  on 
die  o tiler  hand,  rasul's  in  file  reader  con 
tiniiously  having  to  ivll  r  th  legend  to 
determine  the  symbol  hierarchy,  which 
interferes  witli  die  communication  of  the 
geographic  pattern  being  represented. 

Thera  are  some  cartographic  conven¬ 
tions  winch  relate  to  the  gradation  of  colors 
for  quantitative  thematic  mapping  1  Dent, 
1985'.  The  Simple  Hue  Plan  is  a  on. -color 
scheme  which  relies  on  variations  in  color 
value  to  achieve  contrast  between  an- a  sym¬ 
bols.  and  ui  ■  spililis.li  die  visual  hierarchy. 
For  example,  symbolization  would  be 
computed  of  a  graded  series  ringing  from  a 
light,  high- value  hue  for  the  representation 
of  die  lowest  data  elements  to  progressively 
darker  shades  of  die  same  color  as  class  lim¬ 
its  increase. 

Anothi  r  gradation  scheme  is  die  Part- 
Sfiectml  Plan  which  uses  colors  in  die 
sequence  m  which  they  occur  in  die  elec¬ 
tromagnetic  spectrum.  'bx-ctral  colors  range 
from  \  iidet,  the  shortest  visible  wavelength, 
consocudvely  dirough  blues,  greens,  yel¬ 
low^.  oranges.  and  reds.  which  :uv 
comprised  of  the  longest  visible 
wavelengths  The  theory  behind  die  Part 
Spectral  Plan  is  corn-' bo  rated  by  a  physio  log- 
ical  phenomenon  known  as  "advance 
ivtreat"  which  hold.-,  dint  short  wavelength 
colors  focus  in  front  of  die  ratina  and  long 
w  "e length  colons  focus  behind.  ( -onse- 


quently,  die  longer  its  wavelength,  the 
closer  a  color  will  appear  to  the  observer. 
The  Part- Spectral  Plan  uses  hue  and  value  to 
differentiate  between  areal  symbols.  For 
example,  classes  could  be  symbolized  by  yel¬ 
lows,  oranges,  and  reds,  with  yellow 
representing  the  lowest  class  limits  and  red 
representing  the  highest  class  limits. 

Map  Production  Mpov  rr  tiie  maps  to 
be  used  in  illustrating  the  various  data 
themes  included  in  die  COE  Southwestern 
Division  Overview  we  it-  produced  using 
GRAFF  software.  An  equal-area  projection 
was  chosen  for  die  base  map  used  in  digit]/.- 
mg.  ’flu  n.  the  map  was  registered  using  an 
arbitrary  point  of  origin  and  meters  as  die 
map  unit.-.  Each  countv  was  digitized,  and 
encoded  with  die  same  number  that  it  was 
■vniva-nted  by  in  the  database  file.  After 
die  '-ncuding.  the  vectorized  base  map  was 
concerted  into  >  cell  file  which  became  die 
b  i:,e  map  for  tiie  reclassifications  that  pro- 
d.iced  die  subsequent  choropleth  maps. 
After  e-v.-li  data  field  was  standardized.  a 
sorted  list  of  the  values  was  run  through  a 
classing  program  to  establish  class  limits  for 
each  map.  Each  county  was  then  assigned 
to  a  class  according  to  the  individual  data 
theme,  and  a  script  was  generated  and  read 
into  the  GRASS  "Greclass"  module  using 
the  rasterized  base  map  as  the  input  data 
layer  to  create  each  new  choropleth  map. 
The  maps  were  then  supported  widi  color 
and  category  information,  and  essential  map 
elements  such  as  dtle,  legend,  date,  data 
source,  and  scale  were  added  to  complete 
tiie  map  production  process. 

In  many  analytical  situations,  being 
able  to  actually  uistinguish  spatial  patterns, 
rather  than  just  looking  at  a  column  of  data 
values,  can  be  an  important  part  of  the 
decision-  making  or  problem-solving  pro¬ 
cess.  The  primary  purpose  in  choropleth 
mapping  is  to  portray  tiie  general  distribu¬ 
tion  of  an  attribute.  And,  with  adherence  to 
a  few  basic  cartographic  design  principles, 
choropleth  maps  can  he  valuabO  tools  in  tiie 
communication  and  interpretation  of  com¬ 
plex  spatial  relationships. 
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ABSTRACT 

The  Geographical  Resources  Analysis  and  Support  System  (GRASS)  is  a  a 
grid-cell  based  Geographical  Information  System  (GIS).  GRASS  is  a  tool  that 
can  be  used  to  manipulate  map  layers  and  perform  analysis  useful  for  environ¬ 
mental  planners  and  land  managers.  Each  map  layer  in  GRASS  is  made  up  of 
tvvo  different  types  daia:  (1)  the  spatial  data  'hat  designates  where  in  space  a 
particular  geographic  feature  occurs,  and  >2)  attribute  data  that  assigns  the  geo¬ 
graphic  feature  a  specific  label.  New  map  layers  can  be  created  from  existing 
layers  by  using  the  RECLASS  function  which  assigns  new  attribute  data  to  the 
existing  spatial  data. 


Reclassing  is  especially  useful  for 
United  States  Department  of  Agriculture  - 
Soil  Conservation  Service  <  USDA-SCS)  soils 
maps,  since  each  mapping  unit  on  a  soils 
map  has  several  soil  properties  and  interpre¬ 
tations  associated  with  it  Map  layers 
representing  these  properties  and  interpreta¬ 
tions  are  useful  for  many  types  of  analysis. 
In  addition,  USDA-SCS  has  their  soil  infor¬ 
mation  entered  into  2  databases  which  can 
be  accessed  through  a  search  and  retreival 
system,  creating  a  readily  available  source 
for  reclass  information.  However,  SCS  soil 
information  is  structured  so  that  most  of  the 
data  is  based  on  soil  taxonomic  units  and 
not  on  the  mapping  units  depicted  on  a  soils 
map.  Reclassing  the  soil  mapping  units  into 
properties  and  interpretations  based  on  taxo¬ 
nomic  units  can  become  confusing,  sincn 
mapping  units  often  contain  2  or  more  taxo¬ 
nomic  units.  Furthermore,  soil  properties 
for  any  particular  taxonomic  unit  are 
recorded  by  soil  horizon.  The  depth  incre¬ 
ments  for  soil  horizons  vary  from  soil  to 
soil,  making  reclassing  for  a  specific  property 
difficult.  Because  the  reclassed  maps  derived 


from  soils  maps  are  useful  and  important  for 
so  many  types  of  analysis,  consideration 
must  be  given  to  the  issues  involved  in 
reclassing  soils  maps. 

RECLASSING  IN  GRASS 

The  Geographical  Resources  Analysis 
and  Support  System  (GRASS)  is  a  Geo¬ 
graphical  Information  System  (GIS) 
developed  at  the  U.S.  Army  Construction 
Engineering  Research  Laboratory,  Cham¬ 
paign,  IL.  GRASS  is  a  tool  for  storing,  com¬ 
bining,  analyzing  and  displaying  multiple 
map  layers  for  use  in  environmental  plan¬ 
ning  and  land  management.  It  is  a  grid-cell 
based  GIS,  but  does  have  some  vector 
display  capabilities. 

A  map  layer  within  GRASS  is  made  up 
of  two  types  of  data;  ( lithe  spatial  data  that 
designates  where  in  space  a  particular  geo¬ 
graphic  feature  occurs,  and  ( 2)  attribute  data 
that  assigns  the  geographic  feature  a  specific 
label.  For  instance  a  vegetation  map  layer 
would  consist  of  spatial  data  that  puts  the 
areas  of  specific  vegetation  types  in  the 
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correct  position  in  space  and  attribute  data 
that  records  what  type  of’  vegetation  com¬ 
munities  are  present. 

Since  spatial  and  attribute  data  are 
entered  and  stored  separately  in  GRASS, 
new  map  layers  can  be  created  from  the 
existing  spatial  data  simply  by  assigning  a 
new  set  of  attribute  data  This  is  done  by 
using  the  redass  or  Gredass  function  in 
GRASS.  In  the  above  vegetation  overlay 
example,  the  attribute  data  assigns  each  area 
of  the  map  a  vegetation  type .  Tibs  overlay 
can  be  reclassed  to  create  a  map  represent¬ 
ing  any  of  a  number  of  properties  or  charac¬ 
teristics  of  these  vegetation  types,  such  as 
cover  density,  total  forage  production,  etc... 

In  the  interest  of  saving  disk  space, 
reclass  does  not  actually  produce  a  new  map, 
but  instead,  creates  a  reclass  table  containing 
u  e  new  attribute  data  which  is  stored  and 
used  to  reclassify  the  original  map  layer 
whenever  the  new  reclassed  map  name  is 
requested.  As  far  as  the  user  is  concerned,  a 
new  reclassed  map  has  been  created. 
Because  reclass  tables  are  based  on  the  origi¬ 
nal  map  layer,  neclass  maps  are  only  avail¬ 
able  as  long  as  the  original  map  layer 
remains  in  the  database. 

Reclassing  is  especially  useful  for 
creating  additional  maps  from  original  soils 
maps.  Soil  maps  are  commonly  reclasaed 
into  soil  property  or  soil  interpretation  maps. 
These  types  of  neclassed  soil  maps  are  useful 
as  input  for  various  analyses,  such  as 
evaluating  soil  erosion  status,  siting  a  new 
landfill  or  determining  suitability  fcr  crop 
production.  Another  reason  soils  maps  are 
particularly  suitable  for  reclassing  is  that  the 
United  .States  Department  of  Agriculture  - 
Soil  Conservation  Service  has  put  their  soils 
property  and  soil  interpretation  data  into 
databases  which  can  be  accessed  through  a 
soils  information  system.  Reclassing  can  be 
done  using  a  soils  information  system  and  a 
data  base  management  system  (DBMS),  or 
by  entering  reclass  information  directly. 

SOILS  DATA  SOURCES 

USDA-SCS  (United  States  Department 
of  Agriculture  -  Soil  Conservation  Service) 
is  in  the  process  of  mapping  soils  for  all 
areas  of  the  United  States.  SCS  produces  soil 


survey  reports,  using  nationally  approved 
guidelines  and  definitions.  These  soil  survey 
reports  give  general  descriptions  of  mapping 
units,  as  well  as  estimates  of  soil  properties 
such  as  texture,  permeability,  and  have 
tables  giving  physical  and  chemical  proper¬ 
ties  and  use  interpretations  for  the  soil 
series  and  phases  of  a  soil  series.  Soil  survey 
reports  are  published  for  specific  soil  survey 
areas  which  are  most  commonly  counties  or 
groups  of  counties.  These  reports  can  be 
ordered  by  contacting  either  the  SCS  field 
office  for  the  survey  area  of  interest  or  by 
contacting  the  State  SCS  office  for  the  state 
containing  the  survey  area. 

The  soil  information  contained  in  soil 
survey  reports  is  also  available  through  SCS 
soil  databases.  The  data  developed  in  the 
process  of  making  soil  surveys  are  entered 
into  a  computer  at  the  Statistical  Laboratory, 
lov  e  Shan.  University,  Ames,  Iowa. 

The  data  are  entered  into  two  different 
databases,  SOI-5  .and  SOI-6.  The  SOI-5  is 
the  database  for  the  taxonomic  unit,  usually 
soil  series  (and  phases  of  soil  series).  It  con¬ 
tains  information  from  the  Soil  Interpreta¬ 
tion  Record,  which  consists  of  a  brief  soil 
description,  as  well  as  estimates  of  soil  pro¬ 
perties  such  as  texture,  permeability,  depth 
to  bedrock,  frequency  and  duration  of  flood¬ 
ing,  yield  estimates  of  crops,  woodland  and 
range  production  under  stated  management 
systems,  suitability  or  limitations  of  soils  for 
specified  land  uses,  and  soii  features 
affecting  specified  land  uses. 

The  SOI-6  database  is  the  database  for 
the  mapping  unit.  It  contains  information 
from  the  Map  Unit  Records,  which  consists 
of  mapping  unit  characteristics  (such  as 
slope,  USDA  texture,  flooding  frequency, 
prime  farmland  code),  critical  phase  criteria, 
and  survey  acreage  by  county.  The  SOI-6 
database  does  not,  however,  contain  infor¬ 
mation  about,  specific  properties  (other  than 
those  listed  above)  or  about  use  interpreta¬ 
tions.  This  type  of  information  is  only  in  the 
SOI-5  database. 

It  is  important  to  distinguish  between 
tax  a  in  soil  classification  and  mapping  units 
on  a  soil  map.  Soil  Taxonomy  (Soil  Survey 
Staff,  1975),  makes  the  distinction  between 
the  taxonomic  unit  (or  soil  series,  family, 
great  group,  etc.)  and  the  units  shown  on 
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the  map  (map  units) ,  saving  they  are  two 
different  tilings  and  must  not  be  confused, 
even  if  they  carry  the  same  name.  Taxo¬ 
nomic  units  are  described  and  defined  using 
clear  rules  and  guidelines.  However,  because 
soils  can  vary  greatly  in  their  properties, 
they  rarely  fit  neatly  into  the  bounds  of  the 
taxonomy.  The  mapping  units  often 
represent  variations  from  the  central  concept 
of  the  taxonomic  unit.  In  addition,  mapping 
units  are  used  when  separating  individual 
soil  taxonomic  units  would  be  unpractical. 
For  large-scale  maps  ;  SC6  defines  l;u  te 
scale  maps  as  maps  with  scales  of  1  51.680 
or  larger),  mapping  units  are  mo  a  com 
monly  named  as  phases  of  a  s.u!  series.  Rut, 
soils  can  often  be  too  small  or  ti>o  intricately 
associated  with  otlicr  soils  to  mapped 
separately  at  scales  commonly  used  for  so;l 
mep-s.  In  these  cases.  mapping  units  am 
comm;  nly  named  as  a  complex  of  two  or 
more  soil  .sene'-',  an  association  of  two  or 
more  series,  or  a  combination  of  two  or 
more  undifferentiated  groups,  depending  on 
the  variability  of  the  delineated  map  aieas 
and  on  the  constraints  placed  by  the  scale  of 
the  map. 

APPROACHES  TO  RECLASSING 
SOILS  MAPS 

Information  hr  reclassing  soils  maps 
can  be  acquired  from  soil  survey  rejxirts  or 
from  soil  databases,  such  as  the  SOI-5  and 
SOI-6  databases.  Whether  using  a  soil  sur¬ 
vey  report  directly  or  using  soil  databases, 
there  are  inherent  problems  trying  to  relate 
the  conceptual  taxonomic  unit  (SOI-5)  to 
the  soii  mapping  unit  <  SOI-6)  for  the  pur¬ 
poses  of  reclassing  soil  maps  for  further 
analysis.  It  becomes  difficult  to  assign 
specific  soil  properties  or  interpretations  to  a 
soil  mapping  unit  that  sometimes  includes 
more  tlitui  one  taxonomic  unit  In  particular, 
soil  complexes  present  a  problem  because 
they  can  consist  of  component  soil  series 
that  can  vttry  greatly  in  their  properties  or 
use  interpretations.  Soil  associations  do  not 
seem  to  cause  a  problem,  since  they  are 
usually  mapped  only  when  their  component 
soils  are  similar  in  their  properties  and  use 
interpretations.  In  a  soil  survey  report,  soil 
complexes  are  described  with  the  approxi¬ 
mate  relative  percentages  of  its  component 


soils  included.  When  using  a  soil  survey 
report  to  reclass,  soil  complexes  could  be 
named  with  the  percentages  of  component 
soils  included.  Then,  when  using  the 
reclassed  map  for  further  analysis,  a 
weighted  average  approach  might  be  taken. 
Currently,  the  SOI-6  database  (Map  Unit 
Use  File)  does  not  give  relative  percentages 
of  component  soils  for  soil  complexes. 

One  way  of  approaching  this  problem 
of  reclassing  soil  complexes  using  the  SCS 
databases  is  to  reclass  using  the  values  from 
the  SOI-5  database  for  the  element  of  the 
complex  that  constitutes  the  greatest  area  of 
the  mapping  unit.  Complexes  are  named  by 
listing  the  name  of  the  soil  that  makes  up 
the  greatest  portion  of  the  mapping  area 
first.  If  the  goal  for  reclassing  is  to  create  a 
general  soil  properties  map,  this  approach 
may  be  sufficient.  However,  when  the  map 
is  to  be  used  for  specific  management  pur¬ 
poses,  such  as  suitability  for  pesticide  appli¬ 
cation  or  suitability  for  landfill  cover,  this 
method  may  result  in  classifying  an  area  as 
suitable  when  somewhere  within  the  area 
there  are  soils  with  severe  limitations. 

Another  way  of  reclassing  soil  maps  is 
to  use  a  limiting  factor  approach.  For  this 
method,  soil  complexes  or  associations  (if 
needed)  would  be  assigned  values 
corresponding  to  the  soil  element  that  has 
the  most  limiting  factor  for  the  purposes  of 
the  map.  Of  course,  this  assumes  that  the 
uses  for  the  map  are  known  before  reclass¬ 
ing.  For  instance,  if  a  soil  map  is  being 
reclassed  to  a  map  showing  suitability  for 
basements  with  dwellings,  the  soil  com¬ 
plexes  would  be  given  values  corresponding 
to  the  soil  element  within  them  that  has  the 
most  severe  limitation  for  dwelling  with 
basements.  This  would  prevent  the  area 
mapped  as  a  complex  from  being  classified 
as  good  for  dwellings  with  basements  when 
it  may  actually  contain  a  soil  that  has  very 
high  shrink- swell.  When  using  the  limiting 
factor  approach  for  reclassing  a  soil  map  to 
soil  properties  such  as  pH,  texture,  bulk 
density  or  erosion  factor,  the  ultimate  use 
for  the  map  must  be  known  in  order  to 
reclass  using  the  correct  value  (high  or  low 
values  being  limiting?).  For  instance,  if  a 
soils  map  is  being  reclassed  to  represent  soil 
permeability  and  the  resulting  map  is  to  be 
used  to  indicate  those  soils  suitable  for 
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landfill  construction,  soil  complexes  should 
be  assigned  values  corresponding  to  the  soil 
element  in  the  complex  that  has  the  highest 
permeability  value.  This  is  done  because 
soils  with  high  permeabilities  have  limita¬ 
tions  for  landfi'!  construction,  since  waste 
materials  may  leach  through  the  soil  and 
reach  the  ground  water  quickly  and  easily.  If 
the  same  soils  map  is  being  reclassed  to 
represent  soil  permeability  for  the  purpose 
of  indicating  soils  with  limitations  to  septic 
tank  construction,  just  the  opposite  approach 
for  reclassing  should  be  used.  Soils  with  low 
permeability  values  are  not  useful  for  septic 
tank  construction. 

The  concept  of  soil  horizons  alsc 
creates  a  concern  when  reclassing  soils  maps 
into  soil  properties  or  use  interpretations. 
Soils  are  defined,  in  part,  by  the  character 
a  id  thickness  of  their  soil  horizons.  In  the 
501-5  database,  soil  properties  are  reported 
in  tables  for  each  soil  horizon.  The  depth  of 
tnese  soil  horizons'  varies  from  soil  series 
to  soil  series.  For  example,  the  soil  surface 
may  be  the  first  5  inches  for  one  soil  and 
the  first  24  inches  for  the  other.  The  second 
horizon  may  be  6-10  inches  for  one  and  9- 
47  inches  for  the  other.  To  get  around  this 
problem,  general  surface  and  subsurface 
categories  can  be  used.  For  example  layer 
1=  first  horizon,  regardless  if  its  0-5  inches 
or  0-24  inches.  Four  layers  should  be 
sufficient  for  most  soils;  (1)  surface  hor¬ 
izon,  (2)  second  horizon,  (3)  third  horizon, 
and  (4)  below  the  third  horizon. 


SOILS  RECLASS  EXAMPLES 

The  following  are  some  of  the  more 
common  soil  properties,  use  interpretations 
and  land  use  suitability  classifications  that 
may  be  of  interest  to  land  managers.  This 
type  of  soil  information  could  be  used  to 
reclass  an  original  soils  map.  A  suggested 
number  of  layers  to  be  reclassed  are  given 
for  each  soil  property.  When  reclassing  soil 
complexes  and  associations,  an  example  on 
how  to  use  the  limiting  factor  approach  is 
also  given  for  each  soil  property  and  use 
interpretation.  The  value  ranges,  where 
appropriate,  correspond  with  those  set  up  by 
SCS  and  used  in  die  SOI- 5  database.  These 
value  ranges  may  be  used  for  categories  in 
the  reel  ass  map. 


1.  USD  A  texture  Limiting  Factor-use  the 
soils  with  silty  textures.  Map  may  be 
used  for  soil  erosion  analysis,  silty 
soils  erode  more  easily. 

2.  percent  organic  matter  Limiting 
Factor- use  the  soil  with  the  lowest  % 
organic  matter.  Map  may  be  used  to 
indicate  which  soils  have  poor  struc¬ 
ture  and  therefore  easily  compacted  or 
eroded.  Scheduling  maneuver  training 
on  these  soils  should  avoided  in  wet 
conditions. 

>  =  0  but  <  1 

>  =  1  but  <  2 

>  =  2  but  <  5 

>  -  5  but  <  20 

>  =  20 

3.  permeability  (minimum  in/ hr)  Limit¬ 
ing  Factor-create  two  reclassed  maps, 
one  using  the  soil  with  the  highest  per¬ 
meability  and  one  using  soils  with  the 
lowest.  Low  permeability  may  be 
favorable  for  analysis  concerning 
landfill  cover,  while  high  permeability 
may  be  useful  for  septic  tank  construc¬ 
tion.  Low  permeability  may  also  indi¬ 
cate  wet  conditions  during  periods  of 
high  precipitaiton.  Maneuver  training 
may  be  complicated  by  wet,  muddy 
soils. 

>  =  0  but  <  .06 

>  -  .06  but  <  .2 

>  =  .2  but  <  .6 

>  =  .6  but  <  2.0 

>  =  2.0  but  <  6.0 

>  =  6.0  but  <  20.0 

4.  available  water  capacity  (total  inches) 
Limiting  Factor-use  soils  with  low 
available  water.  Map  may  be. used  to 
indicate  soils  with  limitations  for 
revegetation.  Low  available  water 
would  be  detrimental  for  plant  growth. 

>  =  0  but  <  3 

>  =  3  but  <  4 

>  =  4  but  <  5 

>  =  5  but  <  6 

>  =  6 


erosion  factors  (K  and  T)  Limiting 
Factor-use  soils  with  the  highest  K  fac¬ 
tor  and  the  highest  T  factor.  Map  mqy 
be  used  for  erosion  analysis.  Low  K 
factors  mean  the  soil  is  easily  eroded. 
High  T  values  mean 

moist  bulk  density  (maximum  g/cc) 
Limiting  Factor-use  the  soils  with  the 
highest  bulk  densities.  Map  may  be 
used  to  indicate  soils  with  limitations 
for  revegetation.  High  bulk  densities 
can  be  detrimental  for  plant  root 
growth  High  bulk  densities,  however 
may  be  desirable  for  road  building. 

"»  -  0  but  <  1.0 

>  -  1.0  but  v  1.2 

>  =  1.2  but  <  1.4 

>  =  1.4  but  <  1.6 

1.6  but  <  1.8 

>  -  1.8 

pH  Limiting  Factor-use  soils  with  the 
lowest  pH.  Map  may  be  used  to  indi¬ 
cate  soils  with  limitations  for  revegeta¬ 
tion.  Low  pH  is  geneially  detrimental 
for  plant  growth. 

>  =  0  but  <  3.6 

>  =  3.6  but  <  4.5 

>  -  4.5  but  <  5.6 

>  -  5.6  but  <  6.6 

>  6.6  but  <  7.4 

>  -  7.4  but  <  8.5 

>  -  8.5 

salinity  Limiting  Factor-use  soils  with 
the  highest  salinity'.  Map  may  be  used 
for  to  indicate  soils  with  limitations  for 
revegetation.  High  salt  content  can 
generally  be  detrimental  for  plant 
growth. 

>  =  0  but  <  2 
=  2  but  <  4 

>  =-  4  but  <  8 

>  =  8  but  <  16 

16 

flooding  and  high  water  table  - 
includes  the  following  information: 
Limiting  Factor-use  the  soils  with  the 
most  frequent  flooding  and  the  most 
shallow  high  water  table  depth.  These 
soils  could  present  problems  during 


periods  of  high  precipitation. 

a.  flooding  frequency. 

b.  flooding  duration. 

c.  flooding  months. 

d.  high  water  table  depth 
e  water  table  kind. 

f.  high  water  table  months. 


soil  interpretations  and  land  use  suitability 

Limiting  Factor-use  the  soils  with  the  most 
severe  limitations  for  the  following 
interpretations. 

1.  sanitary  facilities  -  includes  ratings  for 
the  following: 

a.  septic  tank  absorption  fields. 

b.  sewage  lagoons. 

c.  sanitary  landfill  (trench) 

d.  sanitary  landfill  (area) 

e.  daily  cover  for  landfill. 

2.  water  management  -  includes  ratings  for 
tlio  following: 

a.  pond  reservoir  area 

b.  embankments,  dikes  and  levees 

c.  excavated  ponds  -  aquifer  fed 

d.  drainage 

e.  irrigation 

f.  terraces  and  diversions 

g.  grassed  waterways 

3.  wildlife  habitat  suitability  -  includes  the 
following  information: 

a  Potential  for  several  habitat  elements, 
b.  Overall  potential  for: 

1.  openland  wildlife. 

2.  woodland  wildlife. 

3.  wetland  wildlife. 

4.  rangeland  wildlife. 

Glossary 

The  following  are  definitions  that  will 
be  useful  for  this  discussion  about  soil  data 
and  reclassing  in  GRASS. 

(1)  Taxonomic  Unit  -  A  named  kind  of 
9oils(  taxon)  that  has  specific  properties  with 
defined  limits  or  ranges  in  chara:teristics. 

Each  ciass  within  the  six  categories  of  "Soil 
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Taxonomy"  is  a  taxonomic  unit. 

(2)  Soil  Series  -  A  group  of  soils  having 
horizons  that  are  similar  in  differentiating 
characteristics,  except  for  differences  in  tex¬ 
ture  of  the  surface  layer  or  of  the  underlying 
material.  Ali  soils  of  a  soils  series  have 
mqjor  horizons  that  are  similar  in  composi¬ 
tion,  thickness  and  arrangement. 

(3)  Phase  of  a  Taxonomic  Unit  -  A  subdi¬ 
vision  of  a  taxon  based  on  texture,  stoni¬ 
ness,  erosion,  salinity,  contrasting  substra¬ 
tum,  etc.  Generally  used  in  combination 
with  descriptive  terms  that  define  the  slope, 
physiographic  position,  or  special  environ¬ 
mental  characteristics  of  the  map  unit.  A 
phase  bridges  the  gap  between  the  taxon  and 
the  map  unit. 

(4)  Phase  of  a  Soil  Series  -  A  subdivision 
bastd  on  one  or  more  characteristics  that  are 
potentially  significant  to  use  or  management 
of  the  soii.  The  most  common  basis  for  del¬ 
ineating  phases  is  slope,  surface  texture, 
erosion,  stoniness,  salinity,  contrasting  sub¬ 
stratum,  physiographic  position,  and  flood¬ 
ing  frequency. 

(5)  Soil  Map  Unit  -  An  area  of  soil(s)  del¬ 
ineated  on  a  soil  map.  It  contains  one  or 
more  taxonomic  units. 

(6)  Consociation  -  A  map  unit  that  is  dom¬ 
inated  by  a  single  kind  of  soils  of  miscel¬ 
laneous  area 

(7)  Undifferentiated  Group  -  Two  or  more 
taxonomic  units  that  are  not  regularly  asso¬ 
ciated  together.  The  members  of  an 
undifferentiated  group  commonly  are  similar 
enough  in  morphology  and/or  behavior  so 
that  separating  them  on  the  map  is  not 
important  for  the  objective  of  the  survey. 
Such  a  unit  is  named  by  combining  the 
names  of  the  taxonomic  units  with  "and". 

(8)  Soil  Complex  -  Two  or  more  taxonomic 
units  that  occur  together  in  a  more  or  less 
regular  pattern  and  are  so  intricately  mixed, 
or  so  small  in  size,  that  it  is  not  practical  to 
separate  them  in  mapping.  The  members  of 
a  complex  commonly  have  contrasting  mor¬ 
phology,  as  well  as  potentially  unique  use  or 


management,  but  cannot  be  separated  at  the 
map  scale  being  used. 

(9)  Soil  Association  -  An  association  is 
similar  to  a  soil  complex  except  the 
members  of  an  association  could  be 
separated  at  scales  commonly  used  on 
detailed  soil  maps  ( 15,840  -  24,000) . 

10)  Soil  Horizon  -  A  soil  horizon  is  a  layer 
of  soil  approximately  parallel  to  the  soil  sur¬ 
face  with  characteristics  influenced  by 
genetic  processes.  Each  horizon  is  separated 
from  adjacent  ones  on  the  basis  of 
differences  in  properties.  The  composition 
and  arrangement  of  soil  horizons  in  a  soil 
profile  ( a  vertical  cut  exposing  the  various 
parts  of  a  soil)  are  the  mqjor  determinants  in 
the  classification,  mapping  and  use  of  land 
areas. 
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Digital  elevation  models  are  fundamental  to  many  Geographic  Informa¬ 
tion  Systems  (GIS)  projects.  Data  sets  such  slope,  aspect,  shaded  relief,  and 
watershed  models  derived  from  DEMs  aie  also  important  to  many  projects. 

However,  none  of  the  digital  elevation  models  currently  available  have  been 
produced  with  your  application  in  mind.  Most  of  these  data  are  characterized 
by  artifacts  that  can  adversely  affect  your  project.  Many  of  these  artifacts  can 
be  detected  and  at  least  partially  alleviated  in  a  GIS  or  image  processing  system. 
Another  advantage  of  such  processing  is  the  possibility  of  completely  docu¬ 
menting  the  work. 

The  Pinion  Canyon  are,  near  Trinidad  and  La  Junta  in  southeastern  Colorado, 
is  used  to  illustrate  the  detection  and  partial  repair  of  DEM  data  in  GRASS. 
Although  the  National  Park  Service  systemused  for  this  work  was  performing 
beta- tests  of  GRASS  3.0,  this  study  used  GRASS  2.0. 

Simple  color  display  may  not  adequately  detect  artifacts  (though  in  Pinion 
Canyon  many  artifacts  are  so  obvious  that  the  simplest  of  visual  inspections  in 
a  GIS  will  detect  them);  more  sophisticated  but  simple-to-produce  displays 
using  very  tight  color  density  slices,  computations  of  slope  and  aspect  often 
show  such  features  of  data 

Simple  data  dropouts,  for  which  the  values  of  individual  grid  cells  at  the  edges 
of  quadrangles  are  zero,  can  be  repaired  by  combinations  of  filtering  and  patch¬ 
ing.  More  complex  dropouts,  where  the  values  may  be  almost  (but  not  quite) 
zero,  or  when?  they  may  be  unrealistically  high  (3700  meters  at  sutures  of  the 
mosaiced  quadrangles  in  some  parts  of  Pinion  Canyon,  where  true  elevations 
are  1200-1800  meters)  cannot  be  corrected  so  simply,  as  patch  will  only  arbi¬ 
trarily  replace  zero  values,  rather  than  user-assigned  values  of  a  map.  In  Pinion 
Canyon,  a  binary  mask  of  areas  with  unrealistic  values  was  created  using  "res¬ 
cale,"  which  was  then  used  to  reassign  bad  values  to  zero  for  repair  by  patching. 

"Gmfilter"  was  used  to  create  custom  filtes  that  reduced  the  patchiness  of  the 
DEM  data  Aspect  is  a  very  unforgiving  display  of  artifacts  in  DEMs  and  was 
used  to  evaluate*  the  results  of  several  "Gmfilter"  windows. 
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Various  versions  of  the  artifacts  in  the  Pinion  Canyon  DEMs  are  shown  in 
detail,  with  discussions  of  a  number  of  options  for  their  repair.  More  sophisti¬ 
cated  filtering  and  neighborhood  analyses  would  help  GRASS  to  better  perform 
quality  control  functions.  Despite  being  incomplete,  current  GRASS  capabili¬ 
ties  help  the  user  to  document/improve  a  database. 


Digital  elevation  models  are  funda¬ 
mental  to  many  Geographic  Information 
System  (GIS)  projects.  Datasets  such  as 
slope,  aspect,  shaded  relief,  and  watershed 
models  derived  from  DEMs  are  also  impor¬ 
tant  to  many  projects. 

However,  none  of  the  digital  elevation 
models  available  from  the  U.  S.  Geologi¬ 
cal  Survey  (USGS),  the  National  Oce¬ 
anic  and  Atmospheric  Administration 
(NOAA),  or  the  Defense  Mapping  Agency 
DMA)  were  designed  with  your  GIS  appli¬ 
cation  in  mind.  Indeed,  the  skeptic  would 
say  that  each  data  set  is  characterized  by 
artifacts,  with  actual  information  being 
somewhat  secondary.  For  example:  1.) 
Early  digital  elevation  models  (DEMs)  were 
created  to  help  produce  molds  for  the  plas¬ 
tic  relief  maps  sold  by  the  DMA  in  the 
1960s.  It  is  not  surprising  that,  when  some¬ 
one  tried  to  use  them  analytically, 
s/he  found  some  undesirable  charac¬ 
teristics,  such  as  concentrations  of  digital 
values  around  the  contours  on  the  paper 
maps.  Compute  slopes  from  such  data 
and  you  get  near-zero  values  almost  every¬ 
where  but  for  areas  mid- way  between  con¬ 
tours  on  the  paper  maps,  where  the 
"roundoff’  from  one  contour  value  to  the 
next  occurs  in  the  digital  data.  Not  the 
beet  way  to  model  floodplains  around  your 
prospective  dam  site. 

2.)  Some  DEMs  are  produced  by  digi¬ 
tizing  with  one  line  spacing,  then  resam¬ 
pling  to  a  closer  or  a  coarser  spacing.  With 
one  type  of  DEM,  values  are  digitized 
along  lines  separated  by  90  meters,  then 
resampled  to  30- meter  grid  spacings.  One 
can  see  the  cost  justification,  but  what  phy¬ 
sical  justification  allows  this?  These  arc 
not  geophysical  potential  field  data,  where 
the  value  at  any  point  is  a  simple  function 
of  the  values  at  all  other  points  in  space. 
One  could  virtually  digitize  the  terrain 
around  Devil’s  Tower  (National  Monument, 
Wyoming),  yet  miss  the  tower  itself  in 


data  represented  to  have  a  30-meter  grid 
spacing!  Such  data  could  be  a  real  night¬ 
mare  for  GIS  processing  of  a  highway 
design.  (Incidentally,  there  Joes  not  appear 
to  be  a  way  of  repairing  such  data  They 
are  best  thrown  out  [or  perhaps  resampled 
to  more  appropriate  100- m  spacings]) . 

3.  Often  considered  the  "premium" 
DEMs  in  the  7  1/2  minute  USGS  series, 
data  from  the  Gestalt  Photomapper  are  pro¬ 
duced  in  500  meter  square  "patches"  from 
aerial  photographic  stereo  pairs.  These 
patches  are  then  mosaiced  with  inadequate 
horizontal-  vertical  control  to  produce  the 
models.  The  resultant  data  are  often  inap¬ 
propriate  for  contouring,  let  alone  deriving 
such  data  as  slope  and  aspect. 

4.  Global  data  sets  produced  by 

NOAA’s  National  Geophysical  Data 
Center  are  combinations  of  regional  or 
discipline-specific  data  sets  produced  by 
other  laboratories,  often  for  disparate 
interests.  Land  values  mqy  be  digitized 
from  maps  (or  estimated  where  the  maps 

have  no  values)  by  a  meteorological 
laboratory.  Bathymetric  models  created 
by  another  lab  by  digitally  interpolating 
actual  bathymetric  soundings  combined 
with  modelled  values  based  on  concepts  of 
the  shape  of  the  ocean  floor.  Grid  sizes 
may  be  different;  values  on  one  grid  may 
be  based  on  grid  centers,  others  on 
grid  nodes.  Combinations  of  these  data 
sets  may  be  valuable  interim  data  sets  for 
global  modeling.  But  care  should  be  taken 
in  making  these  models. 

5.  Attempts  to  make  DEM  data 

appropriate  for  mosaicing  quadrangles 

into  larger  study  areas  have  not  been  com¬ 
pletely  successful.  Bathymetric  models 
may  use  different  representations  of 

coastlines  from  models  of  land  elevations.  3 
arc-second  DEMs  sometimes  have 

significant  vertical  discontinuities  at 

section-lines,  while  mosaics  of  7  1/2  minute 
DEMs  (which  have  no  overlap  [sometimes 
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at  tiio  expense  of  having  data  gaps!  at 
quadrangle  edges)  can  have  line  or 
column  dropouts,  or  even  sliver:  oi 
extremely  high  values  at  sutures  between 
quadrangles. 

Before  I  sound  overly  critical,  let  me 
say  that  current  efforts  to  produce  digital 
data  sets  are  truly  pioneering.  These 
pioneers  are  forging  up  the  digital  Mis¬ 
souri  river  in  their  digital  canoes,  never- 
imagining  what  kinds  of  Kansas  Cities  we 
will  be  creating  from  their  efforts 
Nevertheless,  while  we  continue  to  try  to 
create  our  Kansas  Cities  from  such  pioneer 
mg  efforts,  we  should  try  to  avoid  building 
roads  that  slide  into  canyons,  bridges  or 
dams  that  collapse  or  flood  unexpected 
areas,  or  dump  radioactive  waste  (unexpect¬ 
edly)  upstream  from  a  major  aquifer. 
Inspection  and  partial  repair  of  data  provided 
to  us  by  others  may  help  us  to  avoid  such 
cailamnies 


IMPROVING  THE  QUALITY  OF  DIGI¬ 
TAL  ELEVATION  MODELS  USING  GIS 

The  convenient  display  capabilities  of  a 
GIS  or  image  processing  system  allows  the 
analyst  to  inspect  data  in  a  variety  of  ways. 
Grey-shade  images,  color  displays  using 
continuous  rainbow  colors,  color  density 
slices  using  "random"  colors  for  many  small 
ranges  of  the  data,  shaded-relief  image's 
(GRASS  aspect  images  are  often  easy-to- 
compute  approximations  of  shaded-relief), 
slope  images,  combinations  with  other 
data,  etc.,  all  have  unique  capabilities  to 
enhance  certain  artifacts  in  a  data  set. 

For  example,  your  data  may  have  been 
inappropriately  supplied  to  you  as  eight-bit 
(0-255)  or  integer  values,  when  they  should 
have  been  supplied  as  decimal  fractions  or 
real  values.  Try  to  compute  slope  from 
gravity  data  provided  as  integers,  and  see 
the  "flat"  areas  interspersed  by  "cliffs" 
where  digital  roundoff  occurs  in  the 
input  data.  This  is  an  inappropriate 
representation  of  the  data.  You  may  be  able 
to  make  limited  use  of  such  data,  but 
they  may  be  inappropriate  for  your  main 
application. 

In  our  specific  case,  production  of 
slope  maps  quickly  helps  the  analyst  to 


spot  major  data  discontinuities  at  sutures 
between  quadrangles.  Very  high  slopes 
along  quadrangle  boundaries  appear  for 
either  data  drop-outs  or  slivers  of  errone¬ 
ously  high  values.  "Random"  color  density 
slice  displays  of  elevation  data  should  look 
a  bit  like  psychedelically  colored  topographic 
contour  maps.  Each  color  slice  should  follow 
the  terrain  in  a  physio  graphically  realistic 
pattern.  If  there  are  rectangular 
grid-like  deviations,  if  there  are  linear 
discontinuities  in  tire  patterns,  you  probably 
have  bad  data  Produce  an  aspect  image. 
Artifacts  should  be  accentuated  in  such  a 
display. 

The  repair  of  the  DEMs  can  be 
divided  into  in  two  forms: 

1.  repair  of  suture  lines  of  mosaics,  and 

2.  u:  much  as  possible,  removing  die 
artifacts  resulting  from  the  specific  data  pro¬ 
duction  methods  in  each  quadrangle,  that 
reduce  the  usefulness  of  the  data  for 
further  processing  for  ones  application. 

Few  Geographic  Information  Sys¬ 
tems  have  the  complete  functionality 
to  handle  errors  in  die  data.  GRASS  is 
not  yet  mature  enough  to  completely 
handle  the  errors  diat  can  be  repaired  by 
the  user,  i  Remember,  it  is  almost  always 
better  to  have  had  die  data  brought  to  a' 
high  a  standard  by  the  producers  of  such 
data  -  and  your  encouragement  of  such 
efforts  by  data  producers  may  be  in 
mankind's  interest  as  ’well  as  your  own.' 

But  GRASS,  as  woll  as  many  other 
GISs  and  image  processing  systems,  has 
patching  capabilities  to  partially  repair  bad 
data  values,  mosaicing  capabilities  to  remo¬ 
saic  quadrangles,  filtering  capabilities  to 
subdue  the  effects  of  Gestalt  Pho¬ 
tomapper  patches,  and  so  forth.  These 
functions  can  serve  to  help  us  improve 
the  quality  of  DEMs  and  other  data.  Ulti¬ 
mately,  expert  systems  will  be  developed 
that  will  direcUy  query  specific  types  of  data 
(rather  than  a  human  interface  between  the 
expert  system  and  the  data  that  both 
reside  on  the  same  computer  as  is 
currendy  often  the  case).  Pattern  recogni¬ 
tion  (machine  vision)  techniques  will 
detect  and  automatically  document  and 
alleviate  the  most  common  types  of  data 


-  28- 


errors. 


USING  ONE  EXAMPLE  TO  ILLUS¬ 
TRATE  THE  STYLE  OF  REPAIR 
TECHNIQUES  FOR  ONE  TYPE  OF 
DIGITAL  ELEVATION  MODEL 

The  Pinion  Canyon  area  between 
Trinidad  and  La  Junta  in  southeastern 
Colorado  is  used  as  an  example  of  the 
procedures  that  can  be  used  in  GRASS  to 
improve  the  usefulness  of  one  type  of 
DEM  for  further  GIS  processing.  Pinion 
Canyon  is  recently  acquired  Army  land, 
part  of  Fort  Carson.  Prior  to  acquisition,  it 
was  ranchland.  A  Grass  GIS  data  base  is 
being  constructed  to  help  manage  die 
environmental  resources  of  the  land.  The 
author  is  investigating  the  use  of  GRASS  to 
produce  hydrologic  models  in  the  area 
Die  work  is  being  done  on  the  MassComp 
5300  -  based  GRASS  system  at  the  Geo¬ 
graphic  Information  Systems  Division  of 
the  National  Park  Service’s  offices  in  Lake- 
wood,  Colorado. 

Digital  Elevation  Models  are  a  funda¬ 
mental  part  of  this  GRASS  data  base.  As 
is  typical  of  a  GIS  exercise,  the  data  were 
not  originally  produced  with  GIS  applica¬ 
tions  (let  alone  the  specific  applications 
needed  by  the  Army  Corps  of  Engineers 
Construction  Engineering  Research  Labora¬ 
tory  or  Fort  Carson  management) .  The 
data  should  be  inspected  for  characteristics 
that  might  affect  GIS  processing.  It  is  also 
worth  alleviating  whatever  negative  artifacts 
the  data  may  have  for  a  particular  applica¬ 
tion.  This  step  in  data  base  development  is 
often  omitted,  to  the  detriment  of  the 
users’  objectives. 

The  digital  elevation  models  of  Pinion 
Canyon  obtained  from  the  U.  S.  Geological 
Survey  were  produced  on  the  Gestalt  Pho¬ 
to  mapper.  This  device  works  directly  with 
aerial  photographic  stereo  pairs  to  produce 
models  within  individual  "patches"  (almost 
square  rectangular  areas).  Several  of  these 
patches  are  then  mosaiced  without  accurate 
vertical  control  to  produce  the  DEM  for 
a  particular  7  1/2  minute  quadrangle. 

The  7-meter  accuracy  described  for  such 
DEMs  is  calculated  by  comparing  values 
at  section  lines  where  adjacent  quadrangles 
have  DEMs.  There  is  no  comparison  with 


actual  locations  of  benchmarks  during 
this  accuracy  assessment,  and  the  sharp  vari¬ 
ations  in  elevation  at  the  edges  of  the 
patches  are  essentially  overlooked  by  the 
producers  of  the  data. 

In  addition,  it  is  a  policy  of  the  pro¬ 
ducers  of  these  data  to  avoid  overlaps  in 
data  coverage  at  the  edges  of  quadrangles. 
Due  to  the  nature  of  the  Universal 
Transverse  Mercator  projection’s  fitting  of  a 
flat  surface  to  the  Earth’s  curviture  and  the 
nature  of  production  of  the  DEM  data,  this 
policy  results  in  slivers  of  data  drop-out 
along  sutures  when  these  quadrangles  are 
mosaiced.  These  data  dropouts  can  have 
zero  value,  very  high  values  (much  higher 
than  any  physical  elevation  in  the  are  a) ,  or 
something  in-  between. 

The  patches  on  the  Pinion  Canyon 
data  are  very  disturbing,  not  unusual  for 
such  DEMs.  Such  artifacts  are  clear  evi¬ 
dence  that  the  data  are  not  produced  for 
rigorous  analysis,  such  as  pattern  recogni¬ 
tion  or  the  computation  of  slope  or  topo¬ 
graphic  aspect  In  some  cases,  even  casual 
inspection  of  the  raw  elevations  is  disturb¬ 
ing,  let  alone  rigorous  modeling  of 
derived  data  sets  (such  as  slope)  in  a 
GIS.  The  latter  may  produce  an  outright 
fallacious  result  without  extreme  caution  in 
the  GIS  processing. 

Many  scientists  are  reluctant  to 
"tamper"  with  the  DEMs,  preferring  to 
accept  the  artifacts  as  given.  But  the  data 
were  originally  produced  with  a  somewhat 
arbitrary  procedure.  When  one  realizes 
that  the  data  are  digitized  on  one  unevenly 
spaced  grid,  then  resampled  to  another 
grid  (without  any  physical  justification  - 
we  are  not  dealing  with  potential  fields 
here!),  and  that  neighboring  (rather  than 
nonexisting  overlapping)  values  are  statisti¬ 
cally  compared  to  check  on  the  vertical  pre¬ 
cision  of  the  data,  we  see  that  the  pro¬ 
ducers  of  the  data  are  using  physically 
misleading  (though  statistically  "valid?") 
methods  to  claim  their  7-meter  accuracy. 
We  should  understand  our  own  objectives 
in  using  these  data,  and  the  conflict 
between  the  original  production  methods 
and  our  objectives.  With  this  in  mind,  we 
should  feel  no  reluctance  about  reworking 
the  data  to  make  them  more  appropriate 
for  our  specific  needs. 
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In  the  Pinion  Canyon  area,  the  sharp 
changes  in  elevation  at  the  edges  of  the 
Gestalt  Photomapper  patches  result  in  inac¬ 
curately  high  values  of  slope,  and  inaccurate 
changes  in  value  of  aspect.  The  patching  is 
poorly  controlled. 

In  a  hydrologic  model  we  are  less 
concerned  with  the  overall  vertical  preci¬ 
sion  than  with  the  relative  distribution 
of  elevation.  Applying  spatial  filtering  tech¬ 
niques  may  alter  the  absolute  values  of 
elevation,  while  locally  improving  the 
relative  values. 

Initial  evaluations  of  the  use  of  spatial 
filters  to  improve  the  DEMs  consisted  of 
repeated  applications  of  the  GRASS  func¬ 
tion  "neighbors"  to  the  display  version  of 
the  DEM  (ELEV.DEM).  3x3  mean  filter¬ 
ing  was  applied  repeatedly.  One  could 
apply  the  random  color  lookup  table  to  the 
raw  elevation  data  and  have  some  trouble 
recognizing  intuitively  logical  landforms  in 
the  data  Repeated  application  of  the 
mean  3x3  mean  filter  led  to  increasingly 
physiographically  realistic  renditions  of  the 
area 

With  the  positive  result  of  this  initial 
test,  the  function  "Grnfilter”  was  used 
to  filter  the  actual  DEM  values 
( ELEV.DEM. TRUE) .  "Grnfilter"  has  the 
disadvantage  of  loading  the  entire  map 
into  memory.  Not  only  this,  but  if  one 
runs  the  function  in  "parallel"  mode  (to 
avoid  corrupting  the  input  data  by  previous 
processing)  one  needs  to  have  both  input 
and  output  data  in  memory.  With  the  4 
megabytes  in  the  National  Park  Service’s 
MASSCOMP  5600,  only  about  1/4  of  the 
Pinion  Canyon  mapset  can  be  processed  at 
once,  thus  requiring  subscening  before  pro¬ 
cessing,  with  subsequent  mosaicking  to 
recreate  the  entire  mapset. 

Experimentation  with  various  filter 
sizes  included  3x3,  5x5,  and  7x7  filters  with 
different  combinations  of  weights. 

First,  1x3  and  1x5  vertical  and  horizontal 
filters  were  applied  to  the  data,  to  see  if 
symmetrical  X  Y  filtering  was  appropri¬ 
ate,  or  if  different  sizes  and/or  weights  were 
reeded  in  the  horizontal  and  vertical  direc¬ 
tions.  Grnfilter  was  run  with  filter  weights 
such  as  tlie  following: 


010  000  00100  00000 
010  111  00100  00000 
010  000  00100  11111 
00100  00000 
00100  00000 

The  3x3  filter  needed  to  be  run  far 
more  times  than  the  5x5  filter  to  produce 
acceptable  smoothing.  It  was  also  found 
that  the  data  were  sufficiently  symmetrical 
in  the  horizontal  and  vertical  directions 
to  permit  the  horizontal  filters  to  be 
combined: 

010  00100 
111  00100 
010  11111 
0  0  10  0 
0  0  10  0 

Applying  such  filters  gready  improved 
the  visual  the  elevation  data  However, 
there  vas  still  an  unrealistically  grid-like 
pattern  in  the  slope  and  aspect  data 
derived  (using  Gslope.aspect)  from  such 
filtered  elevadon  data  Thus  hybrid  filters 
were  produced  that  allowed  diagonally 
positioned  elevations  to  influence  the  result: 

00100 
0  12  10 
1  22  2  1 
0  12  10 
0  0  10  0 

Nodce  that  the  filters  now  include 
weighting  favoring  closer  values  over 
more  distant  values.  This  should  be  phy¬ 
sically  valid,  though  it  probably  is  not  par¬ 
ticularly  more  valid  than  equal  weighting 
of  the  data  as  actually  produced  by  USGS. 

Such  filtering  reduced  the  grid- like 
appearance  of  the  slope  and  aspect  data  cal¬ 
culated  from  such  filtered  DEMs.  It  was 
decided,  however,  to  experiment  with 
increased  filter  size  to  7x7,  as  well  as  with 
increased  weighting  along  diagonals: 

1111111 
1112  111 
1  1  23  2  1  1 
1  2  3  3  3  2  1 
1  1  2  3  2  1  1 
1112111 
1111111 

This  filter  kernel  is  now  being  used 
to  process  the  data  (EIjF1V.DEM.TRUE) 
for  northwestern,  northeastern. 
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southeastern,  and  southwestern  quadrants 
of  the  Pinion  Canyon  mapeet  Current 
assessment  of  the  data  is  that  funning  this 
filter  in  parallel  through  the  data  fewer 
than  four  times  leaves  too  much  patchwork 
gridding  in  the  data,  and  that  more  than 
four  applications  of  the  filter  smoothes  out 
too  much  detail.  Four  applications  leave  a 
combination  of  these  problems:  some¬ 
what  too  much  patchwork  gridding  in 
some  areas,  somewhat  more  smoothing  than 
desired  in  other  areas.  But  this  comprom¬ 
ise  appears  to  be  the  best  for  the  Pinion 
Canyon  data. 


THIS  PAPER  IS  DISTRIBUTED  ON 
A  USER-BEWARE  BASIS.  IT  FAILS  TO 
COMPLETELY  DISCUSS  FILTERING 
AND  PATCHING  OF  BAD  MOSAIC 
SUTURES. 
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Versatilitv  of  GRASS  Data  Layers 
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Construction  Engineering  Research  Laboratory 
P.O.  Box  4005,  Champaign,  H  61824 


ABSTRACT 

The  Geographical  Resource  Analysis  Support  System  (GRASS)  has  been 
implemented  at  several  installations  across  the  U.S.  Each  implementation 
requires  the  development  of  a  set  of  supporting  data  layers.  Over  the  last 
several  years,  CERL  has  supported  its  implementation  by  the  development  of 
these  layers.  This  is  a  retrospective  of  the  work  done  for  several  installations. 
The  paper  reviews  which  layers  were  generated,  how  they  were  used,  how  often 
they  were  used  and  for  what  purposes.  Based  on  which  data  set  configurations 
have  in  the  past  proven  to  be  the  most  versati'e  the  paper  identifies  which 
layers  are  likely  to  provide  the  greatest  return  on  the  development  moneys 
invested  and  how  to  make  these  decisions 


One  of  the  mqjor  components  of  the 
establishment  in  a  Geographical  Resource 
Analysis  Support  System  (GRASS)  Geo¬ 
graphical  Information  System  (G1S),  which 
data  to  generate  to  support  the  usage  of  the 
system  is  an  important  decision.  Maps 
(called  data  layers)  which  are  stored  in  the 
system  are  often  expensive  to  translate  from 
paper  (or  digital)  form  into  the  format  used 
by  GRASS.  In  an  environment  where  budg¬ 
ets  are  limited,  it  is  necessary  to  set  priori¬ 
ties  on  which  data  layers  can  be  generated. 
The  layers  which  must  receive  the  highest 
priority  will  depend  on  the  applications  to 
which  the  GRASS  system  is  intended  to  be 
put  Since  applications  vary  depending  on 
location  and  agency,  so  must  the  desired 
map  layers. 

CERL  has  now  had  considerable 
experience  in  developing  a  set  of  initial  data 
layers  at  several  locations.  Also  CERL  has 
been  involved  in  carrying  out  a  variety  of 
applications  using  these  layers.  This  paper 
will  review  some  of  the  experiences  which 
have  been  gained  and  make  a  set  of  recom¬ 
mendations  based  on  those  experiences. 

Beside  simply  deciding  on  a  group  of 
layers  to  support  a  single  application,  several 


corollary  questions  need  also  to  be  asked.  If 
you  have  identified  a  set  of  layers  to  be 
developed  for  a  particular  purpose,  are  there 
other  applications  to  which  this  set  can  be 
put  so  the  data  layer  development  process 
will  provide  enhanced  value  to  the  final  pro¬ 
duct?  And  if  a  layer  is  developed,  can  the 
categories  easily  be  translated  to  another 
layer  (e.g.  using  the  GRASS  tool  called 
RECLASS)  such  that  you  have  developed 
two  or  more  layers  for  the  cost  of  one?  A 
notable  example  of  this  would  be  generating 
a  map  of  soil  "Fh"  from  the  published  Soil 
Conservation  Survey  County  Soils  Survey 
report.  Choosing  the  initial  data  layer 
configuration  carefully  with  these  considera¬ 
tions  in  mind  can  considerably  enhance  the 
value  and  versatility  of  your  GRASS  data 
base. 

There  are  several  ways  of  determining 
a  configuration  of  complementary  data 
layers.  Often  this  has  been  based  on  previ¬ 
ous  experience  with  data  versatility  and  pro¬ 
fessional  judgement.  Topographic  elevation 
might  be  translated  into  GRASS  format,  not 
because  it  is  important  (elevation  often  is 
however)  but  because  elevation  information 
can,  with  relative  ease,  be  translated  into 
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other  layers  which  have  great  versatility. 
Elevation  data  is  regularly  translated  into  a 
layer  showing  the  degree  of  slope.  This  mqy 
be  used  for  modeling  erosion  potentials. 
Elevation  may  also  be  translated  into  a  layer 
showing  the  aspect  (direction  in  which  the 
sloping  land  faces) .  This  may  be  used  in 
modeling  archeological  site  occurrence 
potential.  These  types  of  considerations  are 
important  in  setting  priorities  for  data  layer 
development. 

Table  f  is  an  initial  response  to  the 
question,  "If  one  were  to  develop  a  general 
list  of  applications  versus  data  layers,  what 
would  such  a  list  look  like?"  Table  I  shows 
such  an  arrangement  of  potential  applica¬ 
tions  arranged  down  the  left  column  and 
data  layers  arranged  across  the  top.  Is  it  rea¬ 
sonable  that  a  data  layer  will  be  useful  in 
carrying  out  one  of  tire  applications?  (The 
applications  listed  relate  to  CERL’s  experi¬ 
ences  in  developing  layers  for  military  pur¬ 
poses!.  At  each  intersection  two  responses 
are  noted:  1.  This  data  layer  is  normally  a 
required  input  to  cany  out  the  application 
under  consideration  or  2.  This  data  layer 
would  be  helpful  in  carrying  out  the  applica¬ 
tion  under  consideration  but  the  modeling 
can  be  carried  out  without  its  presence. 
From  a  matrix  like  this,  we  can  derive  an 
understanding  of  which  data  layers  poten¬ 
tially  have  the  highest  versatility  in  support¬ 
ing  different  applications. 

From  Table  I,  it  is  clear  that  a  few 
layers  stand  out  for  their  versatility  in 
different  applications.  Satellite  or  digitally 
stored  remote  sensed  images  (e.g.  National 
High  Altitude  Photography-  NHAP)  have  a 
high  degree  of  versatility  largely  because  the 
color  or  spectral  data  they  contain  can  be 
reinterpreted  to  indicate  land  cover  or  land 
use  type.  (i.e.  They  may  be  used  to  generate 
a  type  of  vegetation  map,  or  they  may  be 
used  to  imply  cultural  features  such  as 
urbanized  areas.)  Remotely  sensed  images 
also  provide  a  historical  document  of  the 
changes  which  have  occurred  in  an  area. 
Another  example  are  soils  data  Soils  data 
are  versatile  because  their  supporting  reports 
usually  correlate  the  distribution  of  the  soil 
with  a  wealth  of  information  about  the 
characteristics  that  the  soil  type  imply  (e.g. 
its  engineering  properties,  its  fertility,  the 
natural  history  of  its  formation) .  Another, 


topographic  elevation,  is  useful  (as  men¬ 
tioned  before)  because  from  it,  it  is  easy  to 
generate  slope  and  aspect  data  as  well. 

The  usefulness  of  this  chart  comes 
from  realizing  that  if  your  data  layers 
include  slope,  soils,  landcover  and  roads 
developed  initially  to  support  the  application 
of  erosion  control,  you  have  the  set  of 
information  required  to  begin  to  deal  with 
questions  about  forestry  applications. 

At  the  bottom  of  this  matrix  are  two 
rows  which  characterize  1.  the  difficulty  of 
generating  the  data  layer  in  question  and  2. 
the  cost  associated  with  generating  the  data 
layer.  This  information  is  quite  general  and 
can,  in  practice,  vary  greatly.  However,  if  it 
is  important  for  you  to  do  not  only  your  ori¬ 
ginal  erosion  applications,  but  also  forestry, 
by  looking  at  those  last  two  rows,  you  can 
obtain  a  general  feeling  for  the  amount  of 
effort  it  will  require  to  be  able  to  support 
that  additional  analysis  application.  (In  this 
case,  to  do  forestry  will  require  the  acquisi¬ 
tion  of  a  forestry  compartment  data  layer 
and  that  will  be  moderately  costly  and 
moderately  difficult  to  accomplish.) 

Often  a  data  layer  is  not  necessarily 
required  as  an  input  into  an  application,  but 
it  is  easy  and  inexpensive  to  generate.  Thus, 
often  that  layer  is  created  to  be  used  for 
display  and  orientation  purposes.  One  may 
call  the  installation  boundary  layer  such  a 
map.  It  may  be  argued  that  display  and 
orientation  are  required  for  most  applica¬ 
tions.  Thus,  a  distinction  must  be  made 
between  when  layers  are  used  for  an  applica¬ 
tion  and  when  they  are  used  for  display. 

To  define  what  an  application  is  in  a 
GRASS  evaluation,  let  us  make  the  distinc¬ 
tion  upon  reflecting  over  what  makes  a  GIS 
valuable.  The  value  of  a  GIS  is  to  generate 
new  types  of  information  (i.e.  an  analysis 
map)  from  existing  information  (e.g.  from 
the  combination  of  the  soils,  slope,  and 
vegetative  cover  maps) .  This  result  existed 
nowhere  else  previously.  It  is  new  informa¬ 
tion.  A  dollar  value  can  possibly  be 
assigned  to  such  an  analysis  by  assigning 
values  relating  to  the  considerations  of  cost 
avoidance,  increased  maintenance  manage¬ 
ment  effectiveness  or  to  savings  realized  by 
doing  the  analysis  in-house  rather  than 
through  a  commercial  contract  with  its 
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added  overhead  costs.  In  contrast,  though 
it  is  important,  a  layer  which  orients  the 
viewer  does  not  generate  new  information 
not  available  previously.  Also  the  assign¬ 
ment  of  cost  values  from  display  or  orienta¬ 
tion  is  not  straight  forward.  In  addition,  by 
adopting  the  strict  definition  (generating 
new  information)  some  distinction  between 
the  characteristics  of  a  GIS  versus  a  CADD 
(Computer  Aided  Design  and  Drafting)  sys¬ 
tem  can  be  made.  The  primary  purpose  of  a 
CADD  is  to  display  information  visually. 
The  primary  purpose  of  a  GIS  is  to  generate 
new  information,  which  coincidental’}'  is 
alro  highly  visual  in  nature.  (Clearly  this  is 
a  superficial  distinction.  Also,  both  clearly 
overlap  each  other’s  capabilities  even  as 
denned  here.  Eut  this  distinction  has  a  con¬ 
ceptual  basis  in  fact  which  relates  to  o cher 
Questions  e.g.  most  GISs  have  to  po  logic  ally 
fere  need  data  structures  while  a  CADD 
may  or  may  not) . 

Thus  defined  here,  an  application  is  an 
evaluation  for  a  specific  purpose  which 
creates  new  information  and  for  which  some 
cost  effects  can  be  identified. 

CERL  surveyed  many  projects  done 
over  the  last  several  years.  Our  most  com¬ 
pletely  developed  data  bases  and  our  broad¬ 
est  applications  expenences  have  occurred  at 
six  Army  installations  and  one  civil  works 
study  area  They  are:  Forts  Hood,  TX, 
Drum,  NY,  Carson,  CO,  Riley,  KS,  Pinon 
Canyon  Training  Area,  CO,  Hohenfelds 
Training  Area,  (Federal  Republic  of  West 
Germany)  and  Kiethsbupg  Study  Area,  IL. 
These  are  the  locations  examined  in  this 
paper. 

For  each  location,  a  survey  was  done 
of  how  each  existing  data  layer  in  that 
installation’s  current  data  base  was  used. 
Table  2  is  an  example  of  the  information 
collected  for  Pinon  Canyon.  This  informa¬ 
tion  was  then  congregated  into  application 
types  ( Table  3)  so  that  the  applications  can 
be  compared  between  different  installations. 

From  this,  data  layer  types  can  be 
compared  across  installations  as  presented  in 
Table  4,  which  is  similar  in  layout  to  Table  I 
(with  applications  versus  data  types).  The 
difference  is  that  these  data  types  (data 
layers  which  have  been  grouped  into  data 
typesJ  ala^ady  exist  as  part  of  some  data 


base  and  these  applications  have  already 
been  carried  out.  Thus,  Table  1  is  a  gen¬ 
eralized  idea  of  what  can  be  done.  Table  4 
shows  what  hoc  actually  occurred. 

The  intersections  in  Table  4  show  the 
initials  of  the  installations.  They  indicate 
which  data  layers  were  used  for  which  appli¬ 
cations.  Multiple  labels  in  a  single  intersec¬ 
tion  indicate  that  usage  occurred  more  than 
once,  either  at  the  same  installation  or  at 
different  locations. 

The  bottom  row  of  Table  4,  the  Fre¬ 
quency  of  data  type  usage,  is  a  simple  sum¬ 
mation  of  the  data  layer  occurrence  in  that 
column.  This  information  can  be  ordered 
per  Table  5  to  show  the  degree  cf  the  data 
type  versatility  (or  value),  'fable  5  indicates 
that  Lucre  are  some  very  highly  used  data 
types  (e.g.  soils  data,  slope,  imagery)  and 
o tliers  that  seem  to  be  less  versatile.  (Note 
dial  just  because  they  are  less  versatile,  does 
not  mean  that  they  are  not  important:  a 
wildlife  application  might  not  be  reasonable 
without  habitats  identified.) 

There  are  several  different  ways  of 
looking  at  this  data  and  interpreting  its 
meaning.  For  example,  when  a  person  gen¬ 
erates  a  road  map  and  a  boundary  map,  he  is 
really  interested  in  having  land  use  informa¬ 
tion.  Thus  the  fact  that  the  boundary  map 
had  low  usage  may  be  misleading.  To  deal 
with  this  question,  five  general  (not  neces¬ 
sarily  mutually  exclusive)  groupings  were 
developed.  land  usage,  environmental, 
natural  configuration,  topography,  and  data 
management  The  data  types  were  congre¬ 
gated  into  these  groupings  in  two  ways:  1. 
under  a  loose  definition  of  what  should  be 
included  in  that  grouping,  and  2.  under  a 
strict  definition  of  group  membership,  (i.e. 
The  loose  definition  is  inclusive,  the  strict  is 
exclusive.)  The  result  is  presented  in  Table 
6.  The  summation  of  the  frequencies  of 
each  grouping  for  either  the  loose  or  strict 
definition  suggests  that  each  group  has  about 
the  same  degree  of  usefulness  (i.e.  that  the 
summation  numbers  are  roughly  about  the 
same  for  each) .  The  conclusion  from  this  is 
that  a  versatile  GIS  data  base  needs  to 
include  a  variety  of  data  layer  types. 
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Conclusions  and  Recommendations 


The  value  of  a  GIS  is  to  generate  new 
types  of  information  (i.e.  an  analysis  map) 
from  the  existing  information  (e.g.  an  ero¬ 
sion  potential  map  from  the  combination  of 
soils,  slope,  and  vegetative  cover  maps). 
Such  a  result  existed  nowhere  else  previ¬ 
ously. 

Though  the  display  of  information  is 
valuable  in  itself,  a  sharp  distinction  was 
made  in  this  paper  between  using  data  layers 
to  display  information  and  using  data  layers 
to  support  an  application  which  generates 
new  information. 

Co nectly  choosing  and  implementing 
the  data  layers  will  provide  greater  versatility 
to  pursue  GRASS  applications.  Types  of 
data  which  have  been  used  at  CERL  for 
generation  of  new  data  outputs  fall  into  five 
major  groupings  'Table  6'  each  of  about 
equal  potential  v;ilue  depending  on  yo'ir 
location's  particular  needs.  These  groups 
consist  of  various  data  types  which  appear 
again  and  again  in  different  applications  at 
many  locations.  The  actual  data  layer 
developed  depends  on  the  location  and  the 
intended  applications  to  which  the  system 
will  be  put.  Data  layers  which  are  imple¬ 
mented  can  have  other  potential  usages 
(Table  1).  These  odier  uses  will  enhance 
your  data  base  if  carefully  developed  and 
allow  it  to  have  greater  usefulness  than  ori¬ 
ginally  might  have  been  thought  possible. 

Finally,  variations  in  the  data  layers 
adopted  will  clearly  depend  on  data  availabil¬ 
ity.  Though  a  data  layer  may  be  highly  use¬ 
ful,  if  it  is  not  available,  alternative 
configurations  will  have  to  be  identified.  If 
this  is  the  case,  some  of  the  tables  presented 
can  be  useful  to  determine  how  closely 
lelated  specific  data  layers  are  and  how  alter¬ 
natives  not  previously  contemplated  might 
yield  greater  versatility  in  the  data  base’s 
ultimate  usage. 

Reference 

Data  Availability  to  Support  a  Standardized 
Military  Geographical  Information  sys¬ 
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TABLE  I  -  POTENTIAL  APPLICATIONS  FOR  DIFFERENT  DATA  LAYERS 
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Table  2 

Example  Page  of  Survey  Showing 
Data  Layer  Relation  to  Applications 


PI  NON  CANYON 


CELL  NAME 

TITLE 

APPLICATION 

SOURCE 

albedo  1 

Ground  RefTLS  10/80) 

change  detection 

LAND  SAT 

albedo  2 

Ground  Ref.(LS  6/82) 

change  detection 

LAND  SAT 

aspect 

Aspect 

background 

topographic  map 

big_.arroyo.cl 

Class.  NHAP 

Big  Arroyo  Hills 

CERL  testing 

NHAP 

big-arroyo.enh 

| 

Enh.  NHAP 

Big  Arroyo  Hills 

CERL  testing 

NHAP 

boundary 

Install.  Boundary 

LOTA 

original  data 

elevation  j 

Elev. -rescaled 

b:*:kground 

DEM/DMA 

hogback.cl  i 

Class.  NHAP(8/83) 
Hogback 

compar.  class. 

NHAP 

hogback.enh 

Enh.  NHAP(  8/83) 
Hogback 

compar.  class. 

NHAP 

landsat.class 

LndcovClass.  It,  80 

background 

LAND  SAT 

lockwood.cl 

Class.  NHAP  7/83 
Lockwood  Arroyo 

compar.  class. 

NHAP 

lockwood.enh 

Enh.  NHAP  7/83 
Lockwood  Arroyo 

compar.  class. 

NHAP 

quads 

USGS  quads 

background 

original  data 

ranches 

Ranch  Houses 

training  avoidance 

original  data 

range  Jand 

Range/Wdld  Sites 

Las  Animas  Cty. 

potential 

vegetation 

soils.  SCS 

restrict_areas 

Restric  ted_A  re  as 

land  mgt. 

training/ arch, 
ecol.  study 
ranch  houses 

roads 

Roads, Trails, Supply  Rts. 

background 

original  data 

rockcross.cl 

Class.  NHAP  10/83 

Rock  Crossing 

compar.  class. 

NHAP 

rockcross.enh 

Enh.  NHAP  10/83 

Rock  Crossing 

compar.  class. 

NHAP 

slope 

Slope  %  derived 
true  elev. 

background 

topo  map 

soils.pinon 

Pi  non  Canyon 
soils- trin  ad 

background 

soils.SCS 

soils. scs. all 

Soils! Las  Animas) 

LCTA/ 

background 

original  data 

train. ability 

Tmblty.-soils 

trainabiiity 

soils 

train_areas 

Training  Areas 

background 

original  data 

vegetation 

derived- NHAP 

background 

original  data 

windmills 

Windmills 

i  background 

original  data 

TABLE  3  -  DATA  TYPES  USED  AT  DIFFERENT  INSTALLATIONS 
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Landfill  Location 
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Recreation 
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General  Data 
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TABLE  4  -  FREQUENCY  OF  DATA  TYPES  USAGE 
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Manaaement 
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Table  5 

Data  Type  Versatility 


Order  of  Data  Value 


10  Soils  ( and  Reclass) 

8  Slope 

7  Archeology  Data 

7  Imagery 

7  Roads 

7  Ecological  Sites  Data 

6  Hydrography  Related  and  Streams 
5  Distance  From’s 

5  Installation  Land  Use 

4  Training  Compartments 

3  Installations  Boundaries 

3  Topography 

2  Aspect 

2  Noise 

2  Geology 

2  Sites  Data 

2  Non  Satellite  Vegetation 

1  General  Cultural 

1  Windows 

1  Off  Installation  Cultural  Features 
1  Dredge 

1  Landforms 

1  Habitats 
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Table  6 

Data  Versatility  Viewed  in 
Different  Groupings 


GROUP 


DATA  LAYERS  LOOSE  STRICT 


Land  Use 


Boundary  3  3 

Off  Installation  Cultural  1  1 

Imagery  7  7 

Installation  Land  Use  5  5 

Roads  7  0 

Training  Compartments  4  4 

Sites  Data  2  0 

Windows  1  0 

GROUP  TOTAL  30  20 


Environmental  Noise  2 

Distance  From  5 

Imagery  7 

Aspect  2 

Ecological  Sites  Data  7 

Vegetation  (Non  Satellite)  2 
Habitates  1 

GROUP  TOTAL  26 


2 

0 

7 

0 

7 

2 

1 

19 


Natural  Configuration  Imagery 

Soils 

Hydrography 

Slope 

Aspect 

Geology 

Landforms 

GROUP  TOTAL 


7 

10 

6 

8 
2 
2 
1 

36 


0 

10 

6 

0 

0 

0 

1 

19 


Topography  Soils 

Topo 

Slope 

Aspect 

Geology 

Landforms 

GROUP  TOTAL 


10 

3 

8 

2 

2 

1 

26 


0 

3 

8 

2 

0 

1 

14 


Management  Data  Archeology  7  7 

Training  Compartments  4  4 

Sites- Ecological  7  7 

Sites  2  2 

Habitats  1  1 

GROUP  TOTAL  21  21 
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The  Development  of  the  Henrietta  Creek  Watershed  Data  Set 
for  use  by  USDA  Soil  Conservation  Service  in  GRASS  Training 

Richarxl  Fmnchek 

U.S.  Department  of  Agriculture 
Soil  Conservation  Service 
501  Felix  Street,  Bldg  23 
F  O  Box  6567 
Fort  Worth,  Texas  76115 


ABSTRACT’ 

In  the  Food  Security  Act  of  1985.  the  Soil  Conservation  Service  was  given 
the  task  of  identifying  all  highly  erodible  soils  that  were  in  cropland.  Framers 
and  ranchers  that  fell  into  these  categories  are  required  to  have  a  conservation 
pian  if  they  wished  to  participate  in  any  federal  farm  programs.  In  October 
1987,  the  SCS  started  the  GRASS  Pilot  Project  with  seven  States  (VT,  NY, 
WA,  CO.  OK,  MO,  MI)  to  identify  its  use  as  a  GIS  tool  for  helping  SCS,  State, 
Area  and  Field  Office  personnel  with  tV-ir  resource  planning  requirements.  As 
part  of  this  testing  trie  SCS  National  Cartographic  Center,  GIS  Staff,  developed 
a  demonstration  data  set  for  use  in  GRASS  training  and  as  a  guide  in  develop¬ 
ing  similar  data  sets  for  their  particular  area  This  data  set  was  designed  with 
tiie  Field  Offices  in  mind.  Data  layere  were  collected  to  show  the  uses  and 
potential  for  GRASS  as  Field  Office  resource  tool  for  identifying  Highly  Erodi¬ 
ble  Lands  (HEL),  conservation  planning,  watershed  planning,  and  information 
programs. 


Since  the  dust  bowl  days  of  the  1930' s, 
the  U.S.  Department  of  Agriculture  Soil 
Conservation  Service  (SCS)  has  worked  with 
farmers  and  lanchers  in  developing  and 
applying  conservation  practices  to  prevent 
excessive  soil  erosion.  SCS  field  offices 
have  primary  responsibility  in  working  with 
the  local  soil  and  water  conservation  district 
to  implement  those  practices. 

With  the  Food  Security  Act  of  1985 
'FSA>  the  demand  for  SCS  services  has 
jumped  dramatically.  The  act  states  gen 
erally  that  to  remain  eligible  for  USDA  pro¬ 
gram  benefits,  a  farmer  must  follow  a  con¬ 
servation  plan  on  all  highly  erodible  crop¬ 
land  areas  and  not  drain  or  convert  any  wet¬ 
lands  (U.S  Department  of  Agriculture, 
1988).  This  requires  SCS  field  offices  to 
determine  highly  erodible  areas  and  to 
develop  the  necessary  conservation  plans 


with  tire  participating  farmer.  In  some  field 
offices,  these  determinations  exceed  1000  a 
year.  Many  are  done  by  hand  using  existing 
soil  maps  and  areial  photography.  The  plan¬ 
ning  process  can  take  several  hours.  This 
situation  made  it  necessary  for  some  type  of 
GIS  technology  that  would  make  the  field 
office  planning  process  more  efficient. 

In  the  spring  of  1986,  the  USDA  Soil 
Conservation  Service  prepared  a  pilot  test 
plan  for  evaluating  the  Geographic 
Resources  Analysis  Support  System 
(GRASS)  software.  In  the  fall  of  1986,  the 
National  Cartographic  Center  (NC)  was 
designated  as  the  GRASS  user  support 
center  for  the  seven  pilot  test  sites.  These 
test  sites  were  located  in  Oklahoma, 
Colorado,  Michigan,  New  York,  Washing¬ 
ton,  Missouri,  and  Vermont.  Pilot  testing 
officially  started  in  October  of  1987  with  a 
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one  week  training  course  nt  the  NCC  in  Fort 
Worth,  Texas.  Fifteen  people  representing 
the  seven  test  sites  attended  the  training. 
Te  pilot  test  ended  in  May  of  1988  and  final 
meeting  of  the  test  sites  was  held  in  June. 

'Hie  Henrietta  Creek  Watershed  Data 
Set  was  developed  to  support  GRASS  train¬ 
ing  as  well  as  provide  a  resource  base.  SCS 
field  office  personnel  could  use  this  data  as  a 
guide  in  developing  data  layers  for  their  par¬ 
ticular-  area.  The  watershed  covers  approxi¬ 
mately  17,014  acres  in  Tarrant  County, 
Texas. 

Six  polygon  layers  and  two  network 
layers  were  developed.  The  polygon  layers 
included  soils,  landuse,  district  cooperator 
boundaries,  field  boundaries,  transportation 
and  watershed  am  a.  The  network  layers 
were  streams  an  roads.  These  layers  were 
digitized  on  ARC/  IMFO  because  the  MAP- 
DEY  portion  of  GRASS  was  not  yet  ported 
to  SCS  .-\TAT  3B2  equipment. 

In  the  development  of  this  data  set 
there  was  not  one  single  base  that  was  avail¬ 
able  that  would  fit  all  the  different  source 
materials.  The  soils  layer  was  on  a  rectified 
photo  background  (1:20000),  the  landuse 
came  form  color  IR  high  altitude  photo¬ 
graphs  (1.24000),  and  the  rest  of  the  layers 
from  I’SGS  7.5  qua!  sheets  <  1:24000) .  This 
condition  would  be  typically  encountered  by 
field  office  personnel  when  developing  their 
own  data  layers  for  GRASS. 

The  problem  was  to  have  all  the  data 
layers  overlay  with  each  other  and  still  not 
have  to  recompile  everything  to  one  base. 
The  common  theme  to  many  of  these  data 
layers  was  the  transportation  network. 
Many  of  the  other  layers  (district  cooperator 
boundaries,  field  boundaries,  landuse  and 
roads)  would  have  this  layer  in  common 
when  being  developed.  For  example,  a  par¬ 
ticular  field  boundary  would  end  at  the  tran¬ 
sportation  corridor,  along  with  a  type  of  lan¬ 
duse.  The  transportation  corridor  would  also 
be  a  category  in  the  landuse  layer.  There¬ 
fore  tiie  transportation  network  was  made  a 
polygon  layer  and  used  as  a  guide  for  the 
rest  of  the  intersecting  or  corresponding 
layers.  As  the  layers  were  digitized,  all  areas 
that  intersected  at  the  road  would  use  the 
already  digitized  transportation  layer  as  the 
stopping  point. 


When  these  layers  were  moved  into 
GRASS,  several  interpretations  were  made 
from  the  soils  layer  that  included  HEL 
classifications  and  many  different  kinds  of 
soil  characteristics  (such  as  soil  depth,  suita¬ 
bility  for  building  sites,  range  and  pasture 
groups,  etc.).  With  the  original  eight  layers 
their  were  now  32  layers. 

When  training  began  this  data  set 
duplicated  real  life  solutions  to  problems 
encountered  by  people  in  the  field.  With 
the  use  of  masking,  windowing,  and  report¬ 
ing,  HEL  determinations  were  generated 
using  the  field  boundary  layer  and  the 
reclassed  soils  layer.  Other  types  of  plan¬ 
ning  were  also  duplicated  to  show  the  parti¬ 
cipants  that  GRASS  was  capable  of  helping 
them  with  their  soil  landuse  related  prob¬ 
lems. 

Other  types  of  data  are  scheduled  to  be 
included  to  this  data  set.  Imagery  is  the 
next  layer  for  inclusion.  This  w’ould  greatly 
benefit  the  user  in  land  cover  determina¬ 
tions  and  for  a  photo  background  to  conser¬ 
vation  planning,  also  a  link  to  a  soil  data 
base  is  needed  to  make  the  interpretations 
( reclass)  of  the  soils  layer  more  efficient  for 
field  office  personnel.  Finally  the  data  set  is 
to  be  enlarged  to  include  the  portion  of  the 
watershed  that  extends  into  Denton  County’, 
Texas  to  tire  north.  With  this  data  set  the 
NCC  will  be  able  to  introduce  GRASS  tech¬ 
nology  to  the  people  who  will  need  it  the 
most. 
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ABSTRACT 

Low  cost  and  current  input  data  are  essential  if  users  of  geographic  infor¬ 
mation  systems  (GIS)  intend  to  support  accurate  and  efficient  problem  solving. 
High  resolution,  current  SPOT  satellite  imagery’  is  provided  in  standard  formats 
to  meet  such  requirements.  SPOT  data  contains  information  pertaining  to  land 
use/land  cover,  transportation  networks,  coastal  boundries,  urban  growth,  geol¬ 
ogy  and  many  other  geographic  applications.  SPOT  imagery  may  be  used 
directly  in  its  raster  form  for  input  to  a  GIS,  for  example  as  input  to  a 
classification  algorithm.  SPOT  may  also  be  used  as  a  backdrop  from  which  vec¬ 
tors  are  digitized,  such  as  updating  vector  transportation  network  within  a  GIS 
environment.  The  GRASS  software  package  enables  a  GIS  user  to  effectively 
exploit  SPOT  data  in  both  raster  and  vector  formats.  The  vector  and  raster 
capabilities  within  GRASS  enable  GIS  users  to  obtain  current,  powerful  solu¬ 
tions  to  Earth  resource  problems. 


SPOT  is  an  acronym  which  stands  for  0.51  um  to  0.73  um  (Visible 

Satellite  Pour  1‘ Observation  de  la  Terre.  Wavelength) 

SPOT  is  high  resolution,  land-imaging  satel¬ 
lite  system  designed  for  Earth  resource  2.  Multispectral  Imagery  20  meter  resolu- 

applications.  The  SPOT  program  was  ini-  tion  Three  Bands  Spectral  Sensitivity 

hated  in  1977  by  the  French  Government  in  (Visible  Wavelengths) 

cooperation  with  Belgium  and  Sweden,  and 
is  managed  by  the  French  Space  Agency 

(ONES).  SPOT  1  was  launched  on  February  Band  1  0.50  um  to  0.59  um 

21,  1986.  The  spacecraft  is  operated  by  Band  2  0.61  um  to  0.68  um 

CNES  which  owns  the  data  copyright.  The  (Near  Infrared  Wavelength) 

SPOT  data  distribution  is  carried  out  on  a  Band  3  0.79  um  to  0.89  um 

commercial  basis  in  the  United  States  by  the 

SPOT  Image  Corporation  located  in  Reston,  What  are  digital  SPOT  Data?  Digital 

Virginia  SPOT  imagery  is  stored  in  raster  format. 

SPOT  satellite  data  are  available  in  This  means  a  single  SPOT  image  is  stored  in 

three  formats;  digital,  film,  and  print.  A  many  small,  rectangular,  "picture  elements" 

single  SPOT  scene  covers  60  km  X  60  km  called  pixels.  Each  SPOT  pixel  represents  a 

swath 8  on  the  Earth’s  surface.  The  SPOT  reflectance  value  ranging  from  0  (low 

satellite  has  two  High  Resolution  Visible  reflectance)  to  255  (high  reflectance). 

(HRV)  imaging  instruments  onboard  which  When  all  the  pixels  are  viewed  at  the  same 

provide  imagery  in  two  different  modes;  time,  they  represent  a  full  SPOT  image. 

1.  Panchromatic  Imagery  10  meter  reso-  Vector  format  models  store  data  in  X, 

lution  Single  Band  Spectral  Sensitivity  Y  coordinates  or  point,  line,  and  polygon 


•If) 


structures.  Vector  data  models  were  among 
the  first  efforts  for  producing  automated  car- 
tn graphic  products  i  Kolassa  1983.  Ikiequet. 
19.8-1 1 .  Today,  many  geographic  infonnaiion 
systems  utilize  vector  formats  for  data 
storage.  Compatibility  between  diffeteut 
so f twain  systems  for  cartographic  products 
derived  from  satellite  imagery  has  become  a 
problem  i  Latter,  198b1.  This  problem  stems 
fonn  tlie  vast  amount  of  current  satellite 
information  available  in  raster  format  and 
map  producing  software  and  output  devices 
which  utilize  data  m  vector  fc-nnat 

There  art1  many  advantages  and  disad¬ 
vantages  associated  witli  seeing  and  mani¬ 
pulating  data  in  raster  or  zee  to  r  formal 
Kolassa  1983,  Bouquet  1981  however,  the 
raster  to  ve,  .or  data  conversion  process  tyqo 
cally  htts  tv. a  prebfuiu  associated  witli  i; 

1  high  m  crossing  overhead  mid  2' difficulty 
of  assoc  inline  attributes  wuh  newly  created 


vector  Levs, 

points. 

or  pjyfvns  i  Koiessa 

1988  .  Tire  1 

at -st  o.tra 

scenario  would  be  te 

ii‘.  a!  wuh 

:tor  an  i 

risk  i  data  sooarately 

within  a  sii 

'gle  s<  *; 

ware  package.  This 

would  allow 

the  liar 

to  inpuit,  munipuba- 

output  and  store  d  gital  data  in  the  most 
efficient  fonnat  possible,  fis  well  ns  enable 
co-display  of,  nk-ifo  slid  rector  files.  These 
raster  mid  weto;  cupabiliLes  me  found  in 
die  GRASS  software  pack;<ge. 

Why  integrate  Htister  SPOT  Satellite 
Imagery  into  a  G>  oirraphic  infonnation  Sys¬ 
tem'’  Th.  re  an  many  justifications  for  util¬ 
izing  SPOT  Data  in  a  GIS:  l'SPOT  satellite 
imagery  is  Ct’RRKNT.  Data  may  be  col¬ 
lected  several  times  per  month  over  tlie 
same  area  by  utilizing  SPOT s  pointable  mir- 
mrs.  2'vSl>'  ! 1’  sat.  dim  imagery  is  DIGITAL. 
Digital  data  .raves  time  and  money  by  elim 
mating  c>  stlv  manual  processing.  3) SPOT 
anagerv  is  Ml'LTllT.’Rl*OSE.  A  single 
SJ’OT  sc' t  He  may  be  used  for  creating  land 
use  hind  cover  maps  extracting  transporta¬ 
tion  routes,  monitoring  urban  growtli,  plan¬ 
ning  geoiogical  exploration,  to  name  a  few 
applications.  4 > SPOT  imagery  offers  GOOD 
CARTOGRAPHIC  ACCURACY.  SPOT 
panchromatic  data  may  be  used  for  mapping 
tit  scales  of  L  12.000  and  smaller.  Finally, 
5 1 SPOT  satellite  itmigery  is  ECONOMICAL. 
STOT  image?'/  tan  cost  up  to  50' >  less  then 
aerial  photography  or  .acquisition,  interpreta¬ 
tion,  and  map  gem  ration. 


Adavatages  of  using  GRASS  to 
Integrate  SPOT  Imagery  into  a  Geographic 
Information  System.  As  mentioned  above, 
there  are  advantages  and  disadvantages  to 
storing  and  manipulating  data  in  raster  and 
vector  formats,  GRASS  has  both  raster  and 
vector  capabilities  which  enable  a  user  to 
create  new  vector  files  through  co-display, 
create  new  raster  files  and  update  old  one 
files,  such  as  USGS  Digital  Line  Graph 
>  DIG ,  data  GRASS  is  being  used  by  a 
largo  number  of  people  for  a  wide  variety  of 
applications.  This  means  cooperative  efforts 
in  research  may  be  coordinated  and  some 
digital  data  files  may  be  shared.  Finally  , 
GRASS  is  available  to  the  genera!  public  at 
almost  no  cost,  which  is  ideal  for  groups 
operating  on  a  tight  budget. 

Current,  low  cost  input  data  are  essen- 
ti.J  if  users  of  geographic  infonnation  sys¬ 
tems  intend  to  support  accurate  and  efficient 
pmblem  solving.  SPOT  satellite  imagery  is 
current,  cost  effective,  information  source 
for  geographic  information  sytems.  Some 
GIS  applications  best  exploit  data  in  either 
raster  or  vector  format.  The  GRASS 
software  package,  however,  can  manipulate 
data  within  and  among  these  fonnats  to 
meet  the  goals  of  spatial  applications. 
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AUSTRACT 

An  exploratory  data  amtlysis  system,  called  S-GE,  which  integrates  with 
the  GRASS  system,  has  been  designed  and  implemented.  The  system  is  based 
on  the  S  statistical  language  developed  by  Bell  Laboratories.  S  is  an  interactive 
environment  for  data  analysis  and  graphics,  and  it  is  it’s  readily  usable  graphic 
capabilities  that  particularly  distinguish  it  from  other  statistical  systems. 

Since  GRASS  is  capable  of  incorporating  remote  sensed  data,  this  explcrar 
tory  data  analysis  module  allows  the  analysis  of  such  data  along  with  that  of  a 
typical  geographic  data  layers,  such  as  soils  geology,  and  other  such  environ¬ 
mental  data  The  S  module  is  desi.jnod  to  access  the  data  sets  that  are  tran¬ 
sported  via  the  "GRASS  to  S  module”  in  GRASS.  These  data  sets  are  in  a  par¬ 
ticular  form  and  S-GEO  is  designed  to  recognize  and  use  this  unique  data 
representation  for  information  representing  the  various  data  layer  values  for 
point  locations,  such  as  archeological  sites,  and  summary  information  for  all 
cells  of  the  region  of  study.  Delta  from  GRASS  may  be  transported  for  any 
number  of  different  sites  lists,  each  identified  by  a  unique  prefix  attached  to  the 
corresponding  data  sets. 

S-GEO  includes  various  univariate,  bivariate,  and  multivariate  analyses 
modules,  all  with  appropriate  graphic  representation  to  aid  in  analysis,  accessi¬ 
ble  through  a  menu  presentation.  Data  for  different  sites  list  are  accessed  by 
identifying  the  appropriate  prefix  for  the  desired  data  In  addition  to  access  to 
the  geographic  data  from  GRASS,  S-GEO  also  permits  the  incorporation  of 
other  kinds  of  information  regarding  sites.  This  latter  information  is  accessible 
through  a  database  management  system,  hi  this  implementation  INFORMIX  is 
used  to  provide  the  additional  data  study.  The  only  requirement,  however,  is  a 
flat  file  of  data  with  one  record  per  point,  so  other  database  management  sys¬ 
tems  could  be  used.  S-GEO  includes  modules  which  retrieve  and  combine  geo¬ 
graphic  data  from  GRASS  with  the  appropriate  descriptive  data  from  the 
INFORMIX  database.  One  such  module  utilizes  a  subset  of  information,  there¬ 
fore  a  subset  of  points  or  sites,  from  the  descriptive  data  set  and  retrieves  the 
appropriate  geographic  data  for  these  points  from  the  GRASS  data  structure. 
These  data  are  then  maintained  in  one  structure,  the  characteristics  of  which 
are  designed  to  be  like  that  of  data  structure  resulting  from  a  GRASS  to  S  tran¬ 
sport.  Therefore  the  S-GEO  modules  are  moved  from  GRASS.  Another  S- 
GKO  module  allows  the  user  to  identify  any  particular  set  of  points  or  sites  as  a 
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group  to  study  as  a  unit.  This  module  retrieves  data  from  both  the  descriptive 
data  set  and  the  GRASS  data  to  produce  a  GRASS  to  S  data  structure  which 
may  also  access  the  S-GEO  analysis  module. 


A  geographic  information  system 
iGIS)  can  be  defined  as  an  automated  sys¬ 
tem  for  the  storage,  retrieval  and  analysis  of 
spatially  referenced  data.  There  are  two 
basic  kinds  of  GISc,  a  vector-based  system 
and  a  cell-based  system.  In  the  former, 
areas  are  represented  as  vectors  (spatial 
coordinates  locating  lines)  defining 

polygons,  and  this  type  of  GIS  represented 
the  usual  system  of  choice  until  recently. 
The  reasons  for  the  early  preference  of  a 
vector-based  system  over  a  cell  based  sys¬ 
tem  include  the  fact  that  they  allow  the  pro¬ 
duction  of  superior  cartographic  output  and 
tey  were  easy  to  implement  with  the 
hardware  and  software  available  prior  to  the 
mid-1980s.  A  mqjor  shortcoming  of 

vector-based  systems,  however,  is  that  they 
do  not  allow  for  appreciable  statistical  char¬ 
acterization  or  analysis  of  the  geographic 
data  which  they  store. 

A  cell-based  GIS  is  one  which 
effectively  divides  a  spatial  surface  into  a 
rectangular  grid  and  stores,  for  each  grid 
cell,  the  spatial  coordinates  which  locate  the 
cell  on  the  surface  as  well  as  any  discrete  or 
continuous  data  pertinent  to  describing  or 
characterizing  the  surface  of  the  cell.  These 
data  effectively  provide  an  n-dimentional 
matrix  which  can  be  used  to  produce  high 
quality  visual  output,  given  high  resolution 
visual  display  equipment,  and  can  be  used  as 
the  basis  for  extensive  statistical  characteri¬ 
zation  and  analysis. 

During  the  1970s  and  early  1980s, 
cell-based  systems  were  constrained  by  fac¬ 
tors  such  as  inflexible  cell  sizes,  large  data 
storage  requirements,  and  the  high  cost  of 
raster  (cell)  display  devices.  Though  these 
factors  limited  their  application,  cell-based 
systems  were  nonetheless  considered  to 
have  greater  analytical  potential  due  to  the 
ease  with  which  the  data  could  be  subjected 
to  numerical  analyses.  This  potential  was 
demonstrated  by  developments  in  the  area 
of  remote  sensing,  including  the  application 
of  classification  methods  to  analyze  remote 
sensed  scenes. 


Hardware  developments  in  the  mid- 
1980s  and  software  written  to  utilize  this 
hardware,  have  allowed  the  emergence  of 
cell-based  GISs  which  address  the  earlier 
problems.  Modem  cell-based  systems  can 
use  the  many  classification  methods 
developed  in  remote  sensing  as  well  as  a 
variety  of  map  calculator  operations.  How¬ 
ever,  there  has  been  no  cell-based  GIS 
development  to  date  which  encompasses  the 
full  range  of  robust  multivariate  statistical 
techniques  which  are  applicable  to  the  mul¬ 
tidimensional  GIS  data.  This  paper  reports  a 
software  development  which  is  designed  to 
provide  he  full  range  of  statistical  tech¬ 
niques  to  a  particular  GIS,  Geographic 
Resources  Analysis  Support  System 
!  GRASS  3.0). 

GRASS  is  essentially  a  cell-based  GIS 
which  is  interactive  and  allows  for  the  visual 
presentation  of  grid  cell  data  layers  in  two 
dimensions,  as  well  as  3-dimentional  visual 
presentations.  Vector  and  point  data  may 
also  be  stored  and  displayed.  Numerous 
map  layer  types  may  be  represented  for  an 
area  of  interest;  some  data  layers  represent 
basic  raw  data  collected  from  the  surface, 
such  as  elevation  data,  while  other  data 
layers  are  derived  from  one  or  more  other 
surface  representations.  Examples  of 
derived  data  layers  are  slope  and  aspect, 
both  derived  from  the  basic  elevation  data 
Additional  map  layers  may  be  derived  by 
classifying  cells  according  to  their  distance  to 
some  aspect  of  the  landscape  such  as 
streams.  An  analyst  may  also  reclassify  a 
data  layer,  such  as  soils  for  example,  into  a 
new  data  layer  which  gives  a  different  organ¬ 
ization  of  the  basic  information.  One  might 
derive  a  more  general  soils  map  which 
groups  similar  soils  into  fewer  classes,  but 
classes  which  may  have  more  interpretive 
meaning  in  the  analysis  than  did  the  more 
finely  divided  original  soils  map. 

In  most  GIS  applications,  there  are 
many  data  layers  of  interest,  particularly 
given  the  ability  to  derive  new  layers  of 
analytical  interest.  The  resulting  complexity 


-  49  - 


and  multidimensionality  of  GIS  data  sets  can 
make  multivariate  patterning  difficult  to 
assess.  Modem  statistical  developments  in 
exploratory  data  analysis  (EDA)  include 
techniques  which  can  be  useful  in  analyzing 
multivariate  spatial  data  In  fact,  there  is  an 
EDA  system  which  shares  some  of  the 
characteristics  of  GRASS  -  its  interactive 
and  analytical  attributes.  This  EDA  system 
is  the  S  system  ( Becker  &  Chambers  1984) , 
developed  at  Bell  Laboratories,  and  it  is 
interactive  and  strongly  graphics  oriented. 
The  linkage  of  a  powerful  cell-based  GIS 
and  an  interactive,  graphic  statistical  system 
such  as  S  is  both  needed  and  feasible.  A 
GIS  should  not  be  seen  as  an  isolated  sys¬ 
tem  but  rather  as  one  component  in  a 
comprehensive  automated  database  environ¬ 
ment  including  database  management, 
remote  sensing,  and  EDA  components. 
Toward  this  end,  software  to  link  GRASS,  a 
database  management  system,  and  S  has 
been  developed  and  implemented  by  the 
author. 

An  exploratory  data  analysis  module, 
based  on  the  S  statistical  language,  has  been 
developed  to  link  S  procedures  to  GRASS 
databases  as  well  as  to  other  databases  which 
pertain  to  points  of  interest  located  in  the 
analysis  surface.  Since  GRASS  is  capable  of 
incorporating  remote  sensed  data,  this  EDA 
module  allows  the  analysis  of  such  data 
along  with  that  of  typical  geographic  data 
layers,  such  as  soils,  geology,  and  other  such 
environmental  data 

The  new  software  is  designed  to  access 
the  data  sets  that  are  transported  via  the 
"GRASS  to  S  module"  in  GRASS.  These 
data  sets  are  in  a  particular  form,  and  the 
new  EDA  module  is  designed  to  recognize 
and  use  this  unique  data  representation  for 
information  representing  the  various  data 
layer  values  for  point  locations,  such  as 
archeological  sites,  and  summary  informa¬ 
tion  for  all  cells  of  the  region  of  study. 
Data  from  GRASS  may  be  transported  for 
any  number  of  different  sites  lists,  each 
identified  by  a  unique  prefix  attached  to  the 
corresponding  data  sets.  The  user  is  queried 
as  to  the  prefix  or  prefixes  desired  for  any 
particular  analysis,  and  this  is  the  mechan¬ 
ism  for  control  of  the  content  of  the  data 
matrix  to  be  subjected  to  analysis.  The  new 
EDA  software  includes  various  univariate. 


bivariate,  and  multivariate  analyses  macros, 
all  with  appropriate  graphic  representation  to 
aid  in  analysis,  accessible  through  a  menu 
presentation. 

In  addition  to  access  to  the  geographic 
data  from  GRASS,  the  EDA  module  also 
permits  the  incorporation  of  other  kinds  of 
information  regarding  sites.  This  latter 
information  is  accessible  through  a  database 
management  system.  Tn  this  implementa¬ 
tion  INFORMIX  is  used  to  provide  the  addi¬ 
tional  data  regarding  the  points  of  interest  in 
the  geographic  region  under  study.  The 
only  requirement,  however,  is  a  flat  file  of 
data  with  one  record  per  point,  so  other 
database-  management  systems  could  be 
used.  The  new  software  includes  macros 
which,  retrieve  and  combine  geographic  data 
from  GRASS  with  the  appropriate  descrip¬ 
tive  data  from  the  INFORMIX  database. 
One  such  macro  utilizes  a  subset  of  informa¬ 
tion,  therefore  a  subset  of  points  or  sites, 
from  the  descriptive  data  set  and  retrieves 
the  appropriate  geographic  data  for  these 
points  from  the  GRASS  data  structure. 
These  data  are  then  maintained  in  one 
prefixed  structure,  the  characteristics  of 
which  are  designed  to  be  like  that  of  the 
data  structure  resulting  from  a  GRASS  to  S 
transport.  Therefore  the  EDA  macros  are 
equally  usable  with  such  a  data  set  as  with 
the  data  that  are  moved  from  GRASS. 
Another  macro  allows  the  user  to  identify 
any  particular  set  of  points  or  sites  as  a 
group  to  study  as  a  unit.  This  macro 
retrieves  data  from  both  the  descriptive  data 
set  and  the  GRASS  data  to  produce  a 
GRASS  to  S  data  structure  which  may  also 
access  the  EDA  analysis  macros. 

In  summary,  this  EDA  module  pro¬ 
vides  a  link  between  a  powerful  cell-based 
GIS  system  with  the  capability  to  incor¬ 
porate  remote  sensed  data,  discrete  and/or 
continuous  point  data  maintained  in  a  data¬ 
base  management  system,  and  a  powerful 
interactive,  graphic  EDA  system.  It  pro¬ 
vides  an  analytical  database  environment 
from  which  one  can  do  a  wide  variety  of 
analyses,  including  multivariate  analysis  of 
GIS  data 
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ABSTRACT 

GRASS  2.0  was  ported  to  a  PC/AT  under  MS-DOS  as  part  of  the 
development  of  a  prototype  Assessment  System  for  Aircraft  Noise  for  the  U.  S. 
Air  Force.  Information  about  and  complementary  to  map  layers  are  stored  in 
an  ORACLE  relational  database. 


The  1969  National  Environmental  Pol¬ 
icy  Act  (NEPA)  requires  the  U.S.  Air  Force 
to  assess  the  effects  of  their  operations  on 
people,  animals,  and  structures.  Environ¬ 
mental  planners  prepare  analyses  that  range 
from  simple  findings  of  no  significant  impact 
to  preparation  of  extensive  environmental 
impact  documents.  The  analyses  are  typi¬ 
cally  based  on  combinations  of  geographi¬ 
cally  referenced  and  other  documentary 
information. 

Planners  at  remote  Air  Force  facilities 
are  often  hard  pressed  to  obtain  the  timely, 
reliable,  and  comprehensive  information 
needed.  They  often  need  to  present  compo¬ 
site  maps  displaying  information  from 
disparate  sources  (topography,  transportation 
networks,  aircraft  noise  exposure  contours, 
aviation,  population,  land  use,  archeology 
and  cultural  features,  seasonal  habitats  of 
endangered  species) . 

It  is  not  enough  to  locate  and  identify 
potential  aircraft  noise  impacts,  one  must 
also  evaluate  their  significance.  This 
requires  extensive  computation,  but  also 
access  to  various  engineering  models  and 
reference  to  citations  from  specialized  techn¬ 
ical  literature.  Few  computer-based  tools 
are  currently  available  to  facilitate  these  ana¬ 
lyses. 

The  U.S.  Air  Force  Noise  and  Sonic 
Boom  Impact  Technology  Program  (NSBIT) 
is  sponsoring  development  of  an  Assess¬ 


ment  System  for  Aircraft  Noise  (ASAN)  to 
provide  planners  with  the  means  to  conduct 
their  environmental  assessments  in  an 
efficient  and  cost-effective  manner.  The 
first  part  of  the  development  effort,  develop¬ 
ment  of  a  preliminary  prototype  system,  is 
the  topic  of  this  paper.  Development  of  a 
final  prototype  is  now  underway,  in  prepara¬ 
tion  for  delivery  of  the  first  release  of  a  pro¬ 
duction  system  in  1992. 

The  following  were  among  the  funda¬ 
mental  design  constraints  on  ASAN: 

o  users  mgy  not  have  extensive  training  in 
environmental  acoustics  and  NEPA 
requirements. 

o  users  often  work  on  more  than  one 
environmental  at  a  time, 
o  duration  of  assessments  may  exceed  the 
job  tenure  of  the  planner, 
o  users,  often  junior  officers  trained  in  civil 

engineering,  cannot  be  expected  to  have  any  great 
familiarity  with  computing, 
o  users  cannot  be  expected  to  have  access 
to  advanced  graphic  workstation 
hardware. 

o  and,  to  keep  things  challenging,  we  had  less 
than  six  calendar  months  to  put  the 
prototype  together. 

The  design  goal  of  ASAN  is  to  provide  tools 
to  assist  planners  in  their  tasks: 


1.  Process  oriented. 


o  Determining  the  steps  required  to 
complete  the  assessment, 
o  Tracking  the  status  of  the  work 
through  its  stages, 
o  Helping  find  likely  sources  of 
information  for  unstructured 
parts  of  the  data  gathering  and 
analysis. 

o  Organizing  "fixed"  data 
maps,  mission  profiles, 
aircraft  noise  characteristics) 
effectively. 

2.  Analytic. 

o  calculating  to  predict  noise 

exposure  based  on  current  best 
engineering  practice, 
o  assessing  of  impacts  based  on 

current  knowledge  of  the  effects  of 
noise  exposure  on  the  environment, 
o  reporting  the  engineering  and 

assessment  results  in  a  form  useful 
for  inclusion  into  an  final 
document  (e.g.  an  Environmental 
Impact  Statement  or  Finding  of 
No  Significant  Impact) . 

3.  Organizational. 

o  documenting  work  and  decisions  for 
review  by  cognizant  authority, 
o  record  keeping  required  for 
compliance  with  NEPA. 
o  making  supporting  information 
accessible  and  understandable 
to  successors  after  a  planner 
has  been  reassigned  to  other  duties. 

From  the  user’s  perspective,  ASAN’s 
appears  as  shown  in  Figure  1. 

The  A  SAN  target  system  was  a  Zenith 
Z-248  (USAFs  PC/AT  "compatible"  com¬ 
puter)  running  Version  3.3  of  MS-DOS. 
This  relatively  inexpensive  machine  was 
selected  1)  because  it  has  been  purchased  in 
large  quantities  by  the  Air  Force  and  is  thus 
likely  to  be  generally  available  throughout 
the  environmental  planning  community,  and 
2)  because  the  commercial  mass  market  for 
this  and  other  IBM  PC/ AT- compatible  com¬ 
puters  makes  available  low  cost  graphics, 
mass  storage,  and  other  peripheral  equip¬ 
ment. 


It  was  decided  to  develop  ASAN  on 
top  of  existing  GIS  and  relational  database 
management  systems.  GRASS  2.0  was 
selected  as  the  GIS  system,  ORACLE  as  the 
relational  database  manager,  and  U,  a  BBN- 
proprietaxy  screen-oriented  user  interface  for 
the  user  dialogue.  ASAN’s  software  archi¬ 
tecture  is  illustrated  in  Figure  2. 

MicroSoft  C  was  chosen  for  the  imple¬ 
mentation  under  MS-DOS,  largely  because 
of  its  completeness  and  close  compatibility 
with  standard  UNIX  C.  In  the  past  we  have 
ported  software  written  in  C  for  UNIX  to 
the  MS-  DOS/  Micro  So  ft  C  environment 
without  substantive  change. 

The  original  battle  plan  for  integrating 
GRASS  into  ASAN  was  to  port  as  much  as 
possible  of  the  GRASS  software  from  its 
original  UNIX/Masscomp  environment  to 
the  Zenith  Z-248  under  MS-DOS.  Then,  as 
analytic  programs  were  developed  and  needs 
for  geodata  manipulation  identified,  software 
interfaces  could  be  built  to  the  appropriate 
GRASS  features.  A  rngjor  advantage  of  this 
plan  was  the  availability  of  a  stand-alone 
GRASS  system  on  the  ASAN  host  during 
development.  This  could  provide  views  of 
ASAN  data  that  were  not  directly  available 
through  ASAN  itself. 

Like  many  battle  plans,  this  one  did 
not  survive  long  after  initial  contact  with  the 
enemy,  for  several  reasons.  GRASS  was 
apparently  developed  as  a  set  of  independent 
functions.  Users  interact  with  a  consistent 
top-level  shell  or  control  interface  that 
selects  and  invokes  functions.  The  control 
interfaces  inside  most  functions  are  not 
standardized,  however.  Some  functions  take 
LISP- like  statements  as  user  input,  o  there 
take  command  lines  of  the  keywond-and- 
arguments  form,  still  others  use  their  own 
menu  structures. 

Worst  of  all  from  the  perspective  of 
building  ASAN  on  top  of  GRASS,  control 
interfaces  for  many  functions  are  deeply 
embedded  in  the  functions’  execution  logic. 
In  some  cases,  modifying  the  original  code 
to  provide  compatibility  with  the  ASAN 
standard  user  interface  proved  to  be  more 
costly  than  re-implementing  the  functional¬ 
ity  from  scratch. 

GRASS  2.0  code  also  reflects  several 
assumptions  concerning  the  supporting 


hardware  and  software  environment  that  are 
inconvenient  for  porting  efforts.  Parts  of 
GRASS  rely  on  a  UNIX  interprocess  com¬ 
munication  facility  not  available  in  MS- 
DOS,  mostly  to  support  a  multi-user 
environment  with  a  single  shared  display 
device.  In  the  single-  user  ASAN  system, 
this  and  several  similar  issues  were  easily 
resolved.  Dependencies  on  idiosyncratic 
Masscomp  graphics  protocols  were  expected, 
but  surprisingly  few  were  found.  Those  that 
were  found  were  not  of  a  serious  nature. 

Much  more  serious  was  trie  treatment 
of  pointers  and  integers  as  interchangeable 
and  equivalent  quantities.  This  p'-actice  is 
forbidden  by  the  C  language  definition  but  is 
not  detected  by  most  C  compilers.  This 
assumption  rarely  causes  problems  on  32-bit 
computers,  where  both  jointers  and  integers 
are  32  bits  wide.  But  in  our  development 
environment,  it  created  some  of  the  nastiest 
I>orting  problems.  Undetected  instances  of 
intern  hanging  pointers  and  integers  can 
cause  either  constant  or  intermittent 
unpredictable  operation,  inconsistent  pro¬ 
gram  output,  data  corruption,  damage  to 
unrelated  co-resident  software-,  system 
software  crashes,  and  even  disk  and 
firmware  damage 

More  titan  two  hundred  instances  of 
this  problem  were  found  in  the  GRASS 
source  code.  Many  instances  were  found  by 
running  the  UNIX  Lint  utility  over  the 
source  rode  and  ,rv- regaling  everv 

reported  anomaly.  Critical  sections  of  code 
were  analyzed  line  by  line  by  an  experienced 
programmer. 

The  GRASS  code  is  structured  as  a 
multilayered  model.  An  action  that  pro¬ 
duces  graphics  can  pass  through  many  layers 
of  function  calls  before  drawing  commands 
are  produced.  In  tire  interests  of  simplifying 
the  MS-DOS  version,  it  was  decided  to 
reduce  the  number  of  functional  layers  as 
much  as  possible.  One  obvious  reduction 
was  the  combination  of  the  drawing- 
command  layer  on  the  user  side  of  the 
graphics  pipeline  with  tire  aruial  drawing 
code  on  the  device  support  side.  After 
resolving  considerable  confusion  over  the 
term  "window"  (GRASS  uses  the  term  "win¬ 
dow"  to  refer  to  the  entity  called  a 
"viewport;’  in  classical  computer  graphics), 
the  GRASS  window  layer  was  essentially 


eliminated. 

The  usual  difficulties  associated  with 
porting  a  large  UNIX -based  software  system 
to  MS-DOS  were  also  encountered.  The 
most  notable  were  in  the  area  of  memory 
management.  The  Microsoft  C  implementa¬ 
tion  of  the  standard  C  memory  manage¬ 
ment  functions  -  mallocO,  callocO,  freed 
—  well  known  to  be  unreliable  in  large  com¬ 
plex  software  packages,  was  indeed  trouble¬ 
some  in  this  port  as  well.  Since  the  problem 
is  related  to  the  MS-DOS  intrinsic  memory 
limit  structure  of  640k  bytes  in  64k  seg¬ 
ments,  it  can  be  thought  of  as  a  memory 
utilization  problem. 

One  solution  would  be  to  add  expan 
sion  memory  hardware  to  the  system,  and  to 
use  a  memory  management  software  pack¬ 
age  that  utilizes  the  expansion  memory  for 
dynamic  allocation.  Unfortunately  no  such 
package  is  available,  and  neither  time  nor 
funding  w'as  available  in  this  project  to 
develop  one.  The  recent  release  of  MS- 
DOS  version  4.0  may  present  another  solu¬ 
tion,  since  it  reportedly  includes  an  expan¬ 
sion  memory  handler.  But  for  the  ASAN 
prototype  development  effort,  the  simplest 
solution  was  adopted:  problematic  memory 
management  code  was  rewritten  to  employ- 
static  memory. 

Recall  that  lire  goal  of  this  effort  was 
to  construct  an  ASAN  concept  demonstra¬ 
tion  prototype  system  in  a  short  time  with 
iummal  resources,  and  not  specifically  to 
port  GRASS  to  the  MS-DOS  environment. 
As  more  and  more  porting  problems  were 
encountered,  the  development  process  was 
necessarily  refocused  on  the  overall  project 
goal,  and  the  GRASS  presence  in  ASAN 
w-as  drastically  reduced,  until  tire  goal  of 
developing  an  independent  GRASS  within 
ASAN  was  abandoned.  If  a  GRASS  feature 
was  not  required  for  the  demonstration,  it 
was  omitted. 

In  the  case  of  absolutely  essential 
GRASS  functions,  such  as  map  layer  display 
management,  it  eventually  proved  to  be 
quicker  to  write  new  code  from  scratch 
rather  than  to  unravel  and  port  the  original 
GRASS  code.  As  a  result,  the  ASAN  con¬ 
cept  demonstration  prototype  system 
software  does  not  contain  any  original 
GRASS  code,  even  though  GRASS  geodata 
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file  structure  concepts  and  file  formats  were 
retained.  Raster  data  are  stored  as  "cell" 
files;  vector  and  point  data  are  stored  as 
"digit"  files  (used  by  standard  GRASS  as  an 
intermediate  format  in  some  internal  and 
conversion  processes) .  In  this  manner,  the 
data  bases  developed  for  the  ASAN  proto¬ 
type  are  not  lessened  in  value,  and  in  fact 
can  be  further  enhanced  on  standard 
GRASS  workstations. 

As  useful  and  effective  as  a  GIS  is  for 
many  ASAN-related  purposes,  its  capabili¬ 
ties  fall  short  of  an  environmental  planner’s 
needs.  For  example,  much  of  the  informa¬ 
tion  is  not  inherently  georeferenced,  e.g., 
aircraft  noise  and  performance  characteris¬ 
tics.  ASAN  also  contains  an  elaborate  cita¬ 
tion  index  to  the  technical  literature,  a 
Rolodex-like  capability,  and  various  other 
.ion-georeferenced  information.  A  conven¬ 
tional  database  is  more  appropriate  for  such 
information  than  a  GIS. 

Some  other  limitations  of  geoinforma¬ 
tion  systems  in  general  and  GRASS  in  par¬ 
ticular  also  limit  the  usefulness  of  a  purely 
GIS  approach  to  solving  the  environmental 
planners’  problems.  For  example,  the  range 
of  sound  pressures  of  interest  can  vary  over 
a  range  of  about  15  orders  of  magnitude, 
while  small  local  variations  are  important. 
This  precision  is  beyond  the  capacity  of  the 
GRASS  cell  file  structure. 

Further,  analyses  of  noise  impacts  on 
buildings,  ruins,  or  historical  sites  often 
require  consideration  of  a  large  number  of 
parameters.  For  example,  great  detail  might 
be  required  about  the  nature  of  a  structure; 
its  age,  construction,  and  use;  its  occupants 
and  times  of  occupancy;  and  so  forth.  In 
addition,  the  sources  of  information  and 
dates  of  entry  or  modification  must  be 
tracked  for  several  purposes:  to  create  a 
complete  record  of  decision,  to  evaluate 
currency,  and  to  facilitate  performance  mon¬ 
itoring  and  updating.  It  is  convenient  to 
manipulate  this  mass  of  detail  in  ways  that 
cannot  be  readily  accommodated  within  a 
GIS. 

Non-georeferenced  information  in 
ASAN  is  stored  in  an  ORACLE  relational 
data  base,  which  provides  a  full  implementa¬ 
tion  of  the  ANSI  standard  Structured  Query 
Language  on  a  PC.  A  unique  feature  of 


ORACLE  is  that  most  of  its  activities  take 
place  in  extended  memory,  running  in  pro¬ 
tected  mode  on  the  80286  or  80386 
microprocessor.  In  other  words,  except  for 
70  kB  or  so,  the  MS-DOS  operating  system 
does  not  "see"  anything  of  the  database 
software. 

This  was  a  mqjor  consideration  in 
ASAN  development,  because  the  SQL 
engine  is  so  large  that  it  precludes  develop¬ 
ment  of  large  scale  applications  that  must 
share  memory  with  the  DBMS.  Since  the 
aim  was  to  build  a  large  simulation  model 
on  top  of  the  DBMS  (not  merely  to  use  a 
4GL  to  do  simple  stores  and  retrieves),  this 
proved  to  be  an  essential  feature  of  the  data¬ 
base  system. 

The  GRASS-ASAN-ORACLE  proto¬ 
type  stores  non-georeferenced  data  in  nor¬ 
malized  relational  tables,  where  it  is  accessi¬ 
ble  to  a  large  number  of  analytical  routines. 
ASAN  uses  the  relational  approach  for 
discrete  geo -referenced  data,  but  creates  a 
GRASS  file  as  needed  for  display.  A  struc¬ 
ture  similar  to  the  cell  file,  capable  of  stor¬ 
ing  floating  double  rather  than  integer  data, 
is  ultimately  required  for  our  continuous 
geo-referenced  data. 

While  a  normalized  relational  database 
possesses  a  certain  theoretical  cleanness,  this 
comes  at  the  price  of  system  overhead.  For 
a  demonstration  prototype  this  is  not  neces¬ 
sarily  a  problem,  since  such  a  system 
requires  only  limited  amounts  of  data,  and 
an  easily  modifiable  database  is  more  impor¬ 
tant  than  high  speed  performance. 

Our  approach  violates  nonetheless 
some  basic  principles  of  database  design  by 
carrying  large  amounts  of  redundant  infor¬ 
mation  in  GRASS  and  ORACLE  files.  A 
set  of  ORACLE  tables  is  therefore  required 
in  ASAN  to  maintain  synchronization  within 
the  redundant  portions  of  the  database. 
This  is  not  an  undue  burden  because  ASAN 
must  keep  track  of  revision  levels,  entry 
dates,  and  the  "freshness"  of  the  data  in  any 
event.  ASAN  continually  checks  that  one 
piece  of  information  does  not  conflict  with 
another,  and  that  a  particular  set  of  user- 
specified  information  is  in  fact  a  valid  com¬ 
bination  of  possible  inputs.  An  additional 
check  for  database  redundancy  fits  naturally 
with  this  requirement, 
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Of  course  there  is  one  mqjor  caveat: 
One  can  view  information  directly  with 
either  the  geodatabase  or  conventional  data¬ 
base  systems,  but  it  is  an  absolute  necessity 
that  the  ASAN  shell  be  used  to  modify 
information.  The  internal  audit  trail  loses 
file  synchrony  if  ASAN  is  bypassed  to 
update  them. 

Storage  of  information  about  the  vari¬ 
ous  map  layers  in  ORACLE  permits  formu¬ 
lation  of  interesting  questions  from  the 
GRASS/ORACLE  combination.  For  exam¬ 
ple,  consider  a  map  layer  containing  the 
habitat  of  an  animal  species.  When  that 
map  layer  was  created  it  was  recorded  in  the 
ORACLE  database  that  it  deals  with  a  par¬ 
ticular  animal  or  group  of  animals.  'This  is 
done  by  including  the  animal's  taxon 
number  from  ASAN's  taxonomy  table  for 
the  animal  kingdom.) 

ASAN  can  not  only  answer  the  ques¬ 
tion  "Where  does  this  animal  live?",  but  can 
also  retrieve  references  in  the  scientific 
literature  concerning  the  animal  from  a 
bibliography  that  is  indexed  by  taxon 
number.  The  production  version  of  ASAN 
will  be  able  to  carry  this  process  one  step 
further.  ASAN  will  eventually  be  able  to 
answer  the  question  "What  do  I  need  to  read 
to  understand  die  impacts  on  the  local 
fauna?” 

The  preliminary  prototype  was  first 
demonstrated  last  winter.  It  performed  all 
of  its  intended  functions  and  was  received 
with  great  interest  by  its  sponsors  and 
members  of  the  environmental  planning 
community.  The  design  of  a  first  opera¬ 
tional  prototype  is  now  under  way. 

The  Air  Force  is  in  the  process  of 
standardizing  on  80386  machines.  This 
hardware  is  a  much  better  engine  for  large 
and  compute-bound  systems  such  as  ASAN. 
MS-DOS,  with  its  640kB  limitation,  does 
not  make  much  sense  in  this  environment, 
but  the  Air  Force  has  not  yet  committed  to 
an  operating  system  for  the  new  machines. 
Development  of  ASAN  will  probably  not 
occur  within  08^2,  which  is  at  present  only 
partly  developed  itself,  and  may  not  be  the 
system  of  choice  in  1992. 

Continuing  development  of  ASAN 
under  MS-DOS  imposes  the  operating 
system’s  limitations  on  ASAN’s  architec¬ 


ture.  Although  it  is  preferable  to  design  a 
software-  intensive  system  for  delivery  in 
1992  for  the  1990’s  desktop  machine, 
development  cannot  continue  in  an  operat¬ 
ing  system  vacuum.  One  interim  solution  to 
this  dilemma  is  to  conduct  the  next  develop¬ 
ment  phase  of  ASAN  in  UNIX.  This  would 
allow  ASAN  to  sit  out  the  battle  in  the 
operating  systems  market  for  as  long  as  pos¬ 
sible.  It  also  means  less  work  porting  new 
GRASS  developments  to  the  eventual 
operating  environ-ment. 

Since  GRASS  is  not  being  utilized 
within  ASAN  as  a  stand-alone  system,  but 
rather  as  a  building  block  for  a  much  larger 
system  with  its  own  user  interaction, 
development  of  a  "layered”  GRASS  (in 
which  function  control  logic  is  separate  from 
execution  logic)  is  highly  desirable.  A  sug¬ 
gested  model  for  future  development  of 
GR,  SS  is  the  approach  taken  by  conven¬ 
tional  databases.  A  modem  DBMS  has  a 
4GL  front  end  so  that  functional  primitives 
can  iJso  be  called  from  application  code 
through  a  well-  defined  protocol.  A  GRASS 
that  includes  user  access  to  its  component 
building  blocks  would  be  a  major  step 
toward  bringing  geo -information  systems  to 
a  new  level  of  functional  maturity  and  mak¬ 
ing  GRASS  accessible  to  many  other 
problem- specific  applications. 
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Figure  1:  ASAN  from  the  User's  Perpective 
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Figure  2:  ASAN  Software  Architecture 
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ABSTRACT 

Relational  database1  management  systems  (RDBMS),  have  provided  users 
with  the  ability  to  store,  manage  and  manipulate  large  volumes  of  information 
for  nearly  twenty  yeans.  Since  E.  F.  Oodd’s  early  research  with  the  relational 
model  in  the  kite  1960’ s  these  systems  have  been  refined  and  today  represent  a 
standard  for  information  management.  While  RDBMS  are  traditionally  viewed 
as  text  based  systems  they  can  contain  spatial  reference  data  which  provide  a 
logical  link  to  a  GIS  such  as  GRASS.  This  ability  to  link  text  based  systems 
with  a  GIS  serves  to  extend  the  range  of  information  available  to  the  GIS  user. 
For  example,  UTM  registered  point  data  and  polygon  or  area  data  can  have 
multiple  attribute  associations  which  are  retained  in  the  RDBMS  and  accessed 
from  within  the  GIS. 

The  Arkansas  Archeological  Survey  is  currently  developing  an  interface 
between  GRASS  and  a  number  of  archeological  databases  constructed  using  the 
INFORMIX  relational  database  software  which  supports  the  Structured  Query 
Language  (SQL)  standard.  This  interface  will  allow  the  GRASS  user  to  gen¬ 
erate  sites  lists  and  reports  using  SQL  from  within  GRASS.  Discussion  will 
focus  on  the  rationale  for  this  approach,  the  benefits  it  will  bring  to  GRASS 
user  and  the  progress  male  to  date. 


INTRODUCTION 

The  Arkansas  Archeological  Survey  is 
in  tiie  final  stage  of  designing  an  extension 
to  the  GRASS  GIS  which  will  provide  an 
interface  to  a  number  of  archeological  data¬ 
bases.  These  databases  have  been 
developed  using  INFORMIX,  a  commercial 
database  package  distributed  by  INFORMIX 
Inc.,  of  Menlo  Park  California  The 
INFORMIX  software  supports  the  Struc¬ 
tured  Query  Language  standard  (SQL),  and 
adheres  to  the  relation  model  popularized  by 
E.  F.  Codd  in  the  late  1960’s.  This  paper 
will  examine  both  the  rational  behind  the 
development  of  an  extension  to  GRASS 
which  supporto  an  interface  of  this  type  and 
the  methods  and  strategies  we  employed  in 


designing  this  interface.  Although  the  dis¬ 
cussion  will  focus  on  archeological  applica¬ 
tions  using  particular  databases,  the  need  to 
link  a  relational  database  to  GRASS  is  by  no 
means  peculiar  to  archeology.  In  fact  the 
interface  presented  here  will  be  generalized 
to  accommodate  many  diverse  applications. 
There  are  three  key  issues  which  should  be 
should  be  kept  in  mind  throughout  the  dis¬ 
cussion: 

1)  GIS  applications  may  be  appropriately 
applied  to  any  problem  or  data  set  which 
has  a  spatial  component  regardless  of  scale. 

?)  A  GIS  is  nothing  more  than  a  spatially 
legistered  database. 
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:i i  The  cost  ;issociaU'it  wiLlt  constructing  a 
database,  spattal  or  non-spatial.  dentands 
tit  at  the  information  be  used  in  as  many 
contexts  as  possible. 

Underlying  these  issues  is  a  general 
philosophy  which  emphasizes  a  modular 
approach  to  infommtion  management  and 
automated  analysis.  Within  this  conceptual 
framework  two  major  themes  are  relevant  to 
tile  present  discussion.  First,  any  database 
represents  a  long  term  institutional  invest¬ 
ment  and  because  of  tins  it  must  be  main¬ 
tained  in  a  manner  that  permits  maximum 
i  «age  in  a  wide  variety  of  applications.  This 
can  be  thought  of  <ts  ;i  corjxirate  strategy  for 
database  managenvr.t.  Second,  m  order  to 
facilitate  such  a  strategy  a  toolbox  mental itx 
neetls  to  be  developed  in  which  individual 
application  programs  are  seen  ;is  sop. irate 
but  compatible  tools  which  can  be  used  in 
an  integrated  fashion  to  accomplish  research 
or  mnrotgement  objectives  Under  tiiis  for¬ 
mat  each  tool  '  tin •  t i IS.  the  RDBMS  or 
o titer  applications  programs..  i;  us>.-d  in  ;. 
way  til  at  emphasizes  its  strength  and  no  tool 
is  modified  in  onier  to  perform  tasks  for 
which  it  was  not  originally  designed.  This 
is  tiie  inverse  corollary  to  the  K-TELE 
GINZU  it  slices  it  dices  paradigm  of  inertia 
Simply  stated,  when  you  need  a  hammer  use 
one,  but  when  you  need  a  screwdriver 
don't  try  to  make  the  hammer  do  the 
screwdrivers  iob. 


A  DATABASE  INTERFACE  TO  GRASS, 
WHO  NEEDS  IT? 

GRASS  is  tin  extremely  powerful  and 
comprehensive  software  package  which  is 
c, ip  able  of  manipulating  spatial  data  to 
address  a  wide  range  of  problems.  Given 
tiiis,  why  introduce  additional  features  which 
add  to  its  complexity  and  may  be  responsi¬ 
ble  for  making  the  system  more  difficult  to 
use?  This  approach  can  he  characterized  as 
tiie  IF  IT  AIN’T  BROKE  ...DON’T  FIX  IT 
paradigm  of  progress",  which  has  a  great 
deal  of  merit  particularly  where  computers 
are  involved. 

However,  there  are  sc1  "oral  valid  rea¬ 
sons  for  such  an  undertaking.  First,  the 
concept  of  a  text  based  or  relational  database 
is  almost  synonvmows  with  computer  appli¬ 
cations  Database's,  particularly  ndational 


dauihases  have  become  tin  integral  element 
in  the  day  to  day  operation  of  businesses, 
the  Federal  government  and  research  outlets 
across  the  country.  In  these  wide  ranging 
contexts  people  have  amassed  an  extraordi¬ 
nary  volume  of  data  and  have  come  to  rely 
on  databases  to  maintain  multiple  observa¬ 
tions  on  diverse  data  relationships  in  an 
organized  structure.  This  organization  of 
information  is  tiie  job  that  database  tools  are 
carefully  crafted  to  perform.  If  we  as  GIS 
proponents  we  tv  to  adopt  a  corporate  atti¬ 
tude  to  wants  both  tiie  spatial  and  non- spatial 
database.-  we  have  access  to  we  might  derive 
significant  benefits  from  our  attempts  to 
exchange  data  and  information  between  the 
two. 

I:i  addition  to  these  basic  organiza¬ 
tional  strengths  relational  databases  often 
contain  information  which  is  closely  linked 
t<>  G  S  applications.  For  instance,  much  of 
the  information  stored  in  databases  is  spa¬ 
tially  registered  or  has  a  readily  identifiable 
spatial  component.  This  is  particularly  true 
in  the  ana  of  natural  resource  management. 
Archeology,  for  instance,  attempts  to  regis¬ 
ter  everything  to  a  particular  provenience 
and  vve  have  enterod  vast  quantities  of  data 
de.tling  witii  individual  artifacts,  subsistence 
strangles,  settlement  patterns  and  popula¬ 
tion  dynamics  into  relational  databases. 

Each  of  these  entries  has  correspond¬ 
ing  locational  information  and  while  die 
sc: tie  may  vary  from  centimeters  to  meters 
to  kilometers  the  simple  presence  of  this 
spatially  registered  data  demands  that  tiie 
information  be  subjected  to  tire  type  of  spa¬ 
tial  analysis  normally  associated  with  GIS 
applications.  It  is  suggested  here  that  this 
preponderance  of  locational  data  located  in 
text  based  database.-,  is  not  unique  to 
archeology,  but  might  be  widely  found  in 
any  number  of  applications  oriented  towards 
tiie  environmental  sciences. 

Most  importantly  there  is  a  logical 
linkage-  between  databases  and  GRASS 
which  is  evidenced  by  some  of  the  existing 
GRASS  tools.  The  SITES  module  requires 
that  a  series  of  UTM  coordinates  with  an 
accompanying  tag  or  identifier  be  entered 
into  the  system  to  prepare  a  surface  suitable 
for  positional  analysis.  The  RECTA  SP 
module  requires  that  a  series  of  relationships 
<uv  deftrn  .1  and  input  to  modify  existing  data 
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and  construct  a  new  map  layer.  Each  of 
these  processes  involve  the  input  of  infor¬ 
mation  which  is  maintained  outside  of  the 
GIS.  In  many  instances  this  information  has 
been  previously  entered  into  an  existing 
non  spatial  database  of  one  type  or  another. 

While  GRASS  is  perfectly  capable  of 
handling  these  situations  in  its  present 
configuration  the  methods  list'd  to  conduct  a 
RECLASS  or  tc  generate  a  SITES  list  is 
somewhat  analogous  to  die  hammer  and 
screwdriver  intiaphoi  cited  above,  The 
strength  of  GRASS  lies  in  its  ability  m 
manipulate  and  display  spatial  d.ati.  The 
strengths  of  a  datai'ase  ii«*  in  its  ability  to 
perform  conditional  subse  ts,  to  adjust  '.allies 
be -ed  on  seircU d  criteria  and  to  quickly 
gmi!  rate  reports  witii  multiple  formatting 
our  er.s.  These  features  are  exactly  wiiat  is 
■  f.umd  by  oo  tit  -SITES  and  REOT.ASS. 
i  -.eiefutv  establishing  a  link  to  a  text  based 
datii  ase  is  logical  next  .-tep  in  the  evolu¬ 
tion  of  the  GRASS  sysb  ; i. .  Taking  tliis  su  p 
should  improve  the  ease  with  which 
modules  such  as  SITES  and  RECLASS  un¬ 
executed  ruid  in  .-k Id ition  should  stimulate 
increased  use  of  these  tools  while  incor¬ 
porating  a  much  wider  range  of  valuable 
data.  This  type  of  symbiotic  integration  is 
an  excellent  example  of  the  TOOLBOX 
approach  to  automated  analysis, 

DBGIS  TOOLS:  AN  INTERFACE  ONLY 
A  MOTHER  COLLI)  LOVE 

Integration  is  a  lot  like  time,  it's  a 
ro1  alive  phenomena.  Two  tilings  can  be 
characterized  integrat'd  if  a  simple  con¬ 
nection  is  made  between  them.  However, 
this  is  not  die  degree  of  integration  we  felt 
would  be  most  likely  to  encourage  us-  of  a 
database  link  witii  GRASS.  GRASS  users 
are  already  accustomed  to  an  extremely 
flexible,  friendly  inter 'act  which  accommo¬ 
dates  many  levels  of  user  sophistication. 
Because  of  tins  we  felt  it  was  essentia!  to 
retain  as  much  of  a  GRASS  fee!  as  possible 
leaving  the  actual  database  interface  tran¬ 
sparent  to  tiie  end  user  where  ever  feasible. 

'Du  resulting  suite  of  DataBase  GIS 
tools  iDB  tools-,  attempts  to  achieve  this 
level  of  integration  while  addressing  some 
of  the  issues  outlined  above.  These  tools 
mv  designed  to  be  accessed  from  witJiin 


existing  GRASS  modules  or  from  new 
modules  which  simulate  those  already 
present  in  GRASS  For  the  purposes  of 
development  we  have  relied  on  two  existing 
databases  which  have  been  used  in  ongoing 
research  at  the  Arkansas  Archeological  Sur¬ 
vey.  The  AMASDA  database  is  a 
comprehensive  inventory  of  over  22,000 
archeological  sites  with  information 
measuring  over  130  attributes  including 
UTM  easting  and  northing.  The  second 
database  used  during  development  is  smaller 
and  contains  census  oriented  data  from 
over  700  counties  encompassed  within  the 
COE  Southwestern  Division.  In  this  case' 
“ach  county  polygon  received  a  unique 
identifier  enabling  us  to  treat  this  data  in 
much  the  same  way  as  one  would  treat  a 
map  layer  representing  training  areas  on  a 
military  installation.  However,  as  noted 
above-  tilt  usefulness  of  tiiese  tools  is  by  no 
means  restricted  to  such  a  narrow  range 
of  application  and  they  are  being  imple¬ 
mented  witii  an  eye  towards  eventual 
generalization. 


l)B  SIrrES  -  Database  Derived  SITE 
USTS 

The  DB  SITES  module  will  be  created 
as  an  extension  to  the  existing  SITES  pro¬ 
grams  appearing  as  option  number  nine 
on  the  menu.  This  program  will  be  driven 
by  a  direct  interface  to  INFORMIX  and 
will  support  a  query  by  forms  format. 
Under  this  format  the  GRASS  user  will 
be  temporarily  placed  in  the  INFORMIX 
environment  and  a  data  entry  form  will 
appear  on  the  screen.  At  this  time  the 
user  will  select  the  database  tables  from 
which  to  draw  information  and  enter  values 
into  the  fields  upon  which  tire  query  is  to 
be  based.  In  most  instances  this  process  will 
require  only  a  few  key  strokes.  The  data¬ 
base  system  will  then  take  control  and 
retrieve  the  rows  which  satisfy  the  queiy 
and  exist  within  the  currently  defined  win¬ 
dow.  For  example  in  AMASDA  one 
might  request  all  sites  with  mounds  or 
all  sites  that  have  been  assigned  to  the 
cultural  period  Early  Caddo.  More  com¬ 
plex  queries  might  seek  all  sites  which 
have  truncated  mounds,  and  have  been 
designated  a-  ate  Caddo  and  also  have 


been  subjected  to  nonscientific  investiga¬ 
tions.  Such  a  query  would  allow  us  to 
rapidly  identify  ;ill  known  Late  Caddo 
mound  sites  which  have  been  die  focus  of 
non- authorized  excavations.  The  query 
itself  may  incorporate  wildcard  characters, 
range  values.  character  strings  or  specify 
Boolean  relationships.  Or  ;e  retrieved  the 
rows  will  be  formatted  to  conform  to  a  sites 
list  structure  using  the  INFORMIX  report 
generator  ACE  and  placed  in  the  Ate  Jists 
directory  of  lire  current  LOCATION  - 
MA]\SET.  At  tills  time  tlie  user  is  rotumed 
to  tlie  main  SITES  menu  and  may  begin  to 
work  with  tlie  :  ewly  created  sites  list. 

Although  tiiis  module  has  net  been 
formally  put  in  place  we  have  used  us  basic 
comp)  ner.ts  in  conjunction  with 
AMASI >A.  Tlie  results  of  tiiis  limb'  d  test¬ 
ing  were  very  encouraging.  t.ner  flu- 
course  of  a;,  aftt  niton  we  were  able  to  get: 

•  ate  approximately  tl'irlv  separate  sites  lists 
using  both  simple  a:  d  complex  qtii-ries  to 
tin-  database  1  wa:  •  to  ‘■■‘mpLiS'ze  that 
tilt  st'  sites  lists  wen  generated  using  may 
tlie  most  basic  tyjx-  •.  f  queries  and  that 
they  have  been  devi  iop-d  for  the  panics'- 
of  example.  Wo  have  not  yet.  begun  to  truly 
exercise  die  datah au  lo  take  advantage  of 
tlie  multi  table  querying  capabilities  it  sup¬ 
ports  to  extinct  complex  associations  from 
across  the  state. 


OB  RECLASS  -  Dat  base  Derived 
RECLASS  of  Polygtnal  Data 

Tlie  DB  R  ECLASS  module  will 
automate  die  existing  GRASS  modules 
Reclass  1  G  ..reclass) ,  and  will  permit  the  user 
to  specify  any  associations  which  exist  in  die 
database  as  die  criteria  for  creating  die  new 
map  layer.  This  process  will  simulate  a  GIS 
which  preserves  multiple  attribute  tags  for 
individual  polygons. 

I)B  R  EC  LA  AS  will  be  accessed  from 
die  command  line  using  an  argument  sped 
f>in g  die  GRASS  map  layer  which  is  to  be 
the  object  of  die  reel  ass  operation.  Like  DB 
SITES,  I)B  RECLASS  will  place  die  user 
into  dn  INFORMIX  environment.  At  diis 
lime  die  user  mav  enter  a  single  value, 
multiple  values  or  a  formula  which  is  to 
form  die  basis  of  die  reclass  operation. 
'Ibis  information  i-  tiien  incoro  rated  into 


an  SQL  statement  and  submitted  to  the 
database  which  performs  the  requested 
operations  and  transfers  control  to  the 
ACE  report  writer  which  formats  a  Greclass 
input  file.  Greclass  is  then  executed  using 
diis  file  as  input  and  upon  compledon  all 
necessary  GRASS  support  files  are  con¬ 
structed  and  control  is  passed  back  to  the 
command  line. 

lTsing  this  approach  in  conjunction 
with  die  COE  Southwestern  Division 
census  database  vt-  wen?  able  to  quickly 
construct  a  number  of  choropleth  maps 
which  represented  demographic  change 
measured  at  ten  and  twenty'  year  intervals 
and  a  number  of  archeological  maps  dep¬ 
icting  sit--  densities  ami  levels  of  investi¬ 
gation  throughout  an  eight  stale  region, 
I*  cause  each  polygon,  counties  in  this 
instance,  has  a  unique  number  and  associ¬ 
ate! «  atuibutf-  information  die  reclass 
o;»  ratiun  may  he  quickly  performed  by  die 
duiab'-tso  along  a  number  of  imjiortant 
dimensions. 

Again,  this  approach  is  not  ros- 
t rioted  to  diis  narrow  range  of  application. 
We  have  begun  to  experiment  with  this 
process  using  data  derived  from  soils  maps 
and  county  .soils  association  reconis  and 
have  been  successful  in  quickly  creating 
map  layers  dt  picting  phenomena  such  as 
Eli  and  sou  texture .  Because  DB  RECLASS 
will  accept  an  algorithm  which  is  used  to 
derive  new  values  to  represent  each  polygon 
it  will  function  in  much  die  same  way  as 
Gmapcalc  except  diat  die  calculations  are 
performed  on  columns  within  the  database 
instead  of  between  map  layers  in  the  GIS. 
For  example  in  order  to  standardize  die 
census  data  for  area  we  had  the  database 
divide  die  jxpuiation  value  for  each 
county  by  die  number  of  square  miles 
within  diat  county  to  obtain  an  estimate  of 
population  per  square- mile. 

I)B  WHAT  -  Mouse  Driven  Database 
Attribute  Reports 

The  final  database'  tool  we  are  work¬ 
ing  towards  at  diis  time  is  a  variant  of  die 
Dwhat  Command  supported  by  GRASS. 
I'he  DB  WHAT  module  will  function  in 
much  die  same  way  as  Dwhat  except  diat 
it  will  poll  the  database  and  report  back  on 


any  known  attribute  associations  within 
fixed  window  of  one  kilometer.  Like  Dwhat 
this  will  bo  a  mouse  driven  routine.  The 
user  will  enter  the  DB  WHAT  command 
from  the  command  line  and  a  grapliics 
cursor  will  appear  on  die  display  screen. 
'Hie  user  then  positions  die  cursor  in  the 
approximate  area  for  which  information  is 
wanted  and  clicks  on  the  mouse.  At  diis 
time  die  UTM  coordinates  associated  widi 
the  grapliics  cui’sor  position  are  passed  m 

INFORMIX  and  SQ1.  statements  are  exe¬ 
cuted  to  obtain  all  die  rows  which  fail  within 
one  kilometer  of  that  location.  A!! 
columns  for  the  resulting  rows  ate  then  for¬ 
matted  using  die  ALE  report  wnter  and 
output.  Ideally  this  module  would  report 
di needy  to  die  screen,  however  differential 
processing  speeds  and  die  potential  for  u 
v  s.e  i.-uige  of  variation  in  database  size 

.■equin  tiie  daiabase  search  and  i>i>m 
gt.i.ifiuon  to-  run  in  trie  background  aitd 
write  to  a  task  file. 

We  feel  die  DB  WHAT  module  will 
provide  a  great  deal  of  insight  into  the 
range  of  information  available  in  the  vicin¬ 
ity  of  any  given  location  within  die  GIS  It 
will  function  as  a  snapshot  device  which 
allows  the  user  to  simultaneously  examine  a 
GIS  map  surface  and  a  suite  of  associated 
attributes  which  .are  stored  off-line  in  die 
relational  database. 


INTERFACE  ERRATA  -  SO  MANY 
TOOLS  SO  LITTLE  11  ME 

The  tools  discussed  abovr  ait-  only  a 
small  fraction  of  tiiose  which  could,  and 
hotx'fuilv  will  in  the  future,  extend  the 
capabilities  of  the  GRASS  system.  In  fact, 
tire  interface  we  arc  developing  might 
most  effectively  :>e  viewed  as  a  proof  of 
concept.  The  concept  in  tin's  case  is  not 
just  the  linkfuy  of  GRASS  to  a  relational 
database,  but  ratlier  tin-  idea  that  the 
integration  of  a  number  of  specialized  tools 
can  enhance  the-  environment  for  informa¬ 
tion  management  and  automated  analysis. 
We  have  also  been  working  with  linkages  to 
die  "S"  exploratory  data  analysis  system  and 
have  discussed  die  possibility  of  working 
towards  an  interface  to  a  desktop  publish¬ 
ing  system.  Wi  h  the  arrival  of  X -windows 
it  is  conceivable  dial  a  windowing 


environment  could  be  established  which 
allows  the  user  to  work  at  a  single  display 
which  is  running  GRASS,  a  relational  data¬ 
base  system,  an  exploratory  data  analysis 
package  and  a  desktop  publishing  system. 
In  such  an  environment  the  concept  of 
integrated  tools  might  realize  its  full  poten¬ 
tial  permitting  multiple  applications  pro¬ 
grams  to  execute  simultaneously  while  data 
is  input  and  output  from  one  application  to 
lino  the  r. 

Imagine  the  possibilities! 
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.ABSTRACT 

(’.HASS  (Geographic  Resource  Analysis  Support  System)  is  an  interactive, 
high-performance  Geographic  Information  System  package  designed  to  operate 
on  a  variety  of  based  graphics  workstations.  Recently,  work  has  been  under 
way  at  VC  Berkeley’s  Center  (hr  Environmental  Design  Research  to  migrate 
CRASS  to  the  X-W indents  environment,  which  is  emerging  as  the  standard 
graphics,  windowing,  and  user  interface  system  for  workstations.  X-windows 
provides  a  number  of  advantages  to  the  CIS  application  developer  and  user:  ( 1) 
applications  software  developed  for  one  hardware  platform  is  portable  virtually 
without  modification  to  any  other  platform  running  X\  (2)  X  is  a  networked- 
based  protocol,  meaning  that  users  can  directly  access  data  and  software  resid¬ 
ing  at  any  remote  host  and  display  results  locally;  and  (3)  a  consistent  user 
interface  may  be  maintained  across  a  range  of  platforms  and  implementation 
schemes.  This  paper  x  will  discuss  the  issues  in  moving  GRASS  to  the  *Y 
environment,  both  in  terms  of  the  graphics  requirements  and  the  development 
of  a  user  interface.  It  will  then  describe  a  series  of  implementation  scenaria  for 
GRASS,  including  remote  database  query  and  geoprocessing  with  workstation- 
based  interaction,  GIS  database  distribution  for  local  processing  and  display,  and 
local  or  stand-alone  data  development,  analysis,  and  production.  In  any  of 
these  paradigms,  complete  GIS  functionality  is  available  to  a  decision-maker, 
planner,  resource  manager,  or  other  user. 

This  research  effort  is  being  conducted  at  the  Center  for  Environmental  Design 
Research  under  tire  sponsorship  of  the  Department  of  Landscape  Architecture 
and  the  State  of  California  Department  of  Water  Resources,  with  additional 
cooperation  of  the  US  Army  Corps  of  Engineers,  Construction  Engineering 
Research  Laboratory. 


INTRODUCTION 

The  exploding  interest  in  Geographic 
Information  Systems  that  we  are  witnessing 
as  we  approach  the  1990s  is  manifesting 
itself  in  users’  demands  for  direct  access  to 
timely,  accurate-,  and  understandable  geo¬ 
graphic  information.  More  and  more, 
organizations  are  requiring  that  systems  they 
acquire  or  develop  make  such  information 
readily  available  to  planners,  decision- 
makers,  and  other  users,  who  often  arc-  scat¬ 


tered  throughout  a  region  or  state.  An 
increasing  emphasis  on  standards  for  com¬ 
munication  and  data  exchange  and  on 
“user-friendliness”  to  a  broad  community 
of  users  is  forcing  systems  developers  to 
rethink  traditional  approaches  to  the  design 
of  GIS,  and  indeed  to  the  entire  range  of 
computing  resources. 

The  Geographic  Resource  Analysis  Stq> 
port  System  (GRASS)  has  been  designed  as  a 
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high-performance.  interactive  environment 
for  access  to  geographic  data  management, 
analysis,  and  display  toolsGoran,  1987. 
Developed  and  distributed  at  cost  by  the 
Army  Corps  of  Engineers,  Construction 
Engineering  Research  Laboratory.  in 
cooperation  with  several  federal  agencies 
and  universities,  (.HASS  utilizes  the  new 
generation  of  based  graphics  workstations, 
which  provide  mini  and  supermini  computer 
performance  in  relatively  lav-cost  desktop 
systems.  This  configuration  provides  organi¬ 
zations  with  complete  CIS  capabilities  for 
both  complex  analytical  processing  and  end 
user  access  to  map-based  infonnation. 

.Y- Windows  is  a  software  syr-tetr.  for 
computer  graphics,  windowing,  and  user 
interaction  that  has  been  developed  over  file 
i«.-t  three  ye.tiv  at  Massachusetts  Institute  of 
IVchnology  and  placed  into  the  public 
u ■  main  Windows  is  unique  in  its  strong 
network  orientation  anti  device 
independence.  This  provide?  application 
developer.-  and  users  wuii  in  mendous  flexi¬ 
bility  for  transparently  accessing  software 
and  dam  resources  at  remote  locations  on  a 
heterogeneous  network  of  computers 

The  complimentary  nature  of  CRASS’ s 
flexibility  and  X- Windows'  network  extensi¬ 
bility  suggests  the  value  of  a  merge  of  the 
two.  By  making  the  interactive  capabilities 
of  GRASS  available  for  use  throughout  a 
fully  distributed  envinminent  via  the 
mechanism  of  Y- Windows,  some  of  the 
goals  of  direct  user  access  to  geographic 
infonnation  can  begin  to  be  realized.  This 
merge,  currently  underway  at  UC  Berkeley’s 
Center  fur  Environmental  Design  Research, 
is  being  performed  in  the  context  of  the 
Kern  Water  Bank  project  of  the  California 
Department  of  Water  Resources.  The  goal 
of  tins  particular  effort  is  to  make  a  variety 
of  thematic  layers  available  for  analysis  and 
display  at  various  DWR  offices,  capitalizing 
on  the  rapid  expansion  of  the  .State's  high¬ 
speed  data  communications  network. 

SYSTEM  DESIGN  CONSIDERATIONS 
An  Overview  of  GRASS 

GRASS  is  a  grid  based  CIS  for  mainte¬ 
nance,  analysis,  and  display  of  automated 
map  information.  It  includes  facilities  for 
digitizing  maps  (in  arc/ node  format),  for 


importing  existing  vector  and  raster  data,  for 
jierforming  boolean  overlay,  weighted 
modeling,  tabulation  and  statistics,  and 
other  analyses,  for  displaying  and  interacting 
with  graphic  map  information  at  a  worksta¬ 
tion,  and  for  plotting  and  printing  carto¬ 
graphic  products.  It  also  includes  a  subsys¬ 
tem  for  imagery  analysis  and  integration  of 
image  and  map  data  A  complete  descrip¬ 
tion  of  GRASS  capabilities  is  beyond  the 
scope  of  this  paper,  but  a  number  of  addi¬ 
tional  publications  describe  it  in  great 
detaiiOEEL.  1987aCERL.  1987b. 

Although  GRASS  development,  is  centered  at 
G'EKi.  (the  Army  Corps’  Consuucuon 
Engineering  Research  Laboratory;,  the  fact 
that  GRASS  was  originally  placed  into  the 
public  domain  has  meant  that  other  sites 
have  made  numerous  extensions  to  the  ori¬ 
ginal  system  i  see  GliASSClippings.  the  quar¬ 
terly  new  'letter  published  by  CERLi . 

Kin, ci  the  focus  of  this  paj/er  is  the 
integration  of  GRASS  and  X- Windows,  it  is 
important  In  understand  the  graphics 
environment  in  which  GRASS  operates  from 
both,  a  user’s  and  a  programmer's  perspec¬ 
tive.  For  a  user,  various  display  utilities  and 
tools  have  been  designed  to  provide  a  high 
level  of  user  interaction.  The  user  can 
display  any  cod  map  on  the  screen  (or  over¬ 
lay  multiple  cell  maps),  ovorplot  any 
number  of  vector  or  DLG  files,  and  manipu¬ 
late  the  rosulting  image  wiffi  a  combination 
of  mouse,  keyboard,  ctru.1  pro  gram- driven 
commands.  For  exarr  le.  he  or  she  can 
change  any  or  all  the  „  rs  displayed,  iden¬ 
tify  real-world  coordinates  for  locations  on 
the  screen,  query  the  attributes  associated 
with  a  point  or  region  in  any  thematic  layer 
in  the  database,  zoom  and  pan.  perform 
linear  and  areal  measurements,  generate' 
label  files,  and  correct  or  update  a  data  layer. 
In  addition,  within  the  imagery  subsystem, 
he  or  she  can  geo  reference  imagery  with 
other  map  data,  select  training  sites,  aid 
perform  various  other  display  enhancement 
functions.  A  fundamental  design  goal  of  the 
GRASS- A'- Window's  merge  project  is  to  at  a 
minimum  maintain  all  existing  capabilities  at 
their  existing  level  of  performance,  and  to 
enhance  or  extend  them  wherever  possible. 

>  From  a  programmer’s  perspective. 
GRASS  code  has  been  extensively  modular¬ 
ized  in  order  to  minimize  the  amount  of 


hardware  dependent  software.  Written  in  (’ 
for  the  UNIX/  environment,  most  of  CKASS 
is  essentially  portable  to  a  wide  range  of 
hardware.  The  use  of  only  a  few  device¬ 
dependent  routines  thus  means  that  the 
entire  system  can  be  ported  without  major 
effort  to  new  platforms.1  Isolation  of 
hardware-dependent  code  is  accomplished 
through  the  adoption  of  a  process-driivi 
model Westervelt  et  al.,  1987.  All  CKASS 
utilities  that  diroctlv  or  indirectly  relate  to 
tiie  display  am  written  using  general-purpose 
display  subroutines.  Those  subroutines  are 
in  turn  represented  in  a  sepaiato  library 
i  rasteriib  and  displnylib.  primarily) .  which 
characterizes  tiie  generic  display  primitives 
necessary  to  perform  tiie  desired  operation. 
Finally,  a  separate  library  defines  die  specific 
svsh-m  software1  hareiwaro  calls  tliat  will  pro¬ 
duce  die  graphic  on  the  workstation  screen. 
In  existing  configurations.  tiles-- 
software*/ hiirdvvare*  calls  are*  kernel-based, 
such  as  Sunt  for'  and  Masscomp  CKK. 

At  run-time,  a  background  process- 
tht-  CKASS  ibiirr-  embodying  the  transla¬ 
tion  of  the  generic  display  primitives  into 
die  harelware-dejiendent  systi  m  caiis  is 
stalled  on  the  display  device  or  within  a 
display  window.  Display  processes  com¬ 
municate  directly  with  this  driver  via  an 
interprocess  communication  (’it:,  channel, 
generally  /z'/o's  (System  V  UNIX  ro-called 
nanied  pipes!  or  socket’s  •  Berkeley  UNIX  net¬ 
working!.  The  rationale  for  this  seeming 
complexity  is  that  display  tools  are  identical 
from  machine  to  machine,  and  even  on  a 
specific  computer,  they  may  connect  at  run¬ 
time  to  various  (IKASS  drivers  (if  for  exam¬ 
ple  a  host  was  configured  widi  multiple 
display  monitors).  As  with  die  user 
environment,  a  primary  goal  of  die  (IKASS 
A'- Windows  merge  is  to  maintain  the 
efficiency  of  die  existing  model. 

The  X  -  Wiudo  w:s.  Progcanunmg  Environment 

A’ Windows  is  a  graphics  and  window¬ 
ing  system  for  high-resolution  workstations. 

*  I  MX  is  a  trademark  "f  lV*ll  Lab«*raio  rics 

1  t’urrvntly.  *  I  It  ASS  runs  on  Sun,  Massomp. 
and  AT&T  US2  comput*ars.  using  th**  nalivt'  graph¬ 
ics  system  for  each.  Additional  ports  to  Compaq, 
Macintosh,  arid  Apollo  an-  either  planned  or 
ondorwav 


It  provides  a  user  environment  for  creating 
and  manipulating  windows,  using  a  keyboard 
and  a  mouse  to  provide  input  to  applications 
software,  and  accessing  multiple  programs 
and  systems  concurrently.  Because  of 
numerous  advantages  to  the  system 
developer  and  its  fundamental  device 
independence,  X-Windows  is  emerging  as 
the  standard  for  window  systemsHack, 
1987.  From  a  programmer’s  perspective, 
A'-Windows  is  a  layered  system  allowing 
applications  to  be  constructed  on  top  of 
library  subroutines  and  toolkit  widgets, 
without  regard  for  the  underlying  system 
operations. 

At  its  most  basic  level,  tiie  A'-  Windows 
environment  is  analogous  to  that  of  UK  ASS. 
That  is.  utilities  wishing  to  display  text  or 
graphics  on  a  workstation  screen  communi¬ 
cate  these  requests  to  a  separate  process  that 
is  configured  for  a  particular  hardware  plat¬ 
form.  hi  the  lexicon  of  X,  these-  utilities  are 
called  clients,  and  tiie  hardware  dependent 
process  is  called  tiie  senvr.  Client  applica¬ 
tions  may  exist  on  the  same  actual  CPU  as 
tiie  A  server,  or  they  may  be  running  on 
some  other  node  on  tiie  network,  that  may 
not  even  have  the  same  hardware  architec¬ 
ture.  X- Window's  differs  from  other  win¬ 
dowing  and  graphics  systems  precisely 
because  of  this  reliance  on  a  network 
pro  toco  IScheiflerGettys,  1986.  All  client- 
server  communication  is  via  simple,  asyn¬ 
chronous  byte  streams  sent  over  standard 
network  protocols  such  as  TCP/IP  <  Tivnsport 
Contivl  ProtocolAnteniet  Pivtocol) . 

Because  of  this,  all  X  clients  are  device 
independent,  sending  instructions  (defined 
in  XZifri  via  network  or  interprocess  com¬ 
munication  to  the  X  server  on  a  local  or 
remote  host  specified  by  a  unique  name  or 
address.  Servers  run  as  continuous  back¬ 
ground  processes  on  any  addressable  host, 
listening  for  display  requests  and  mediating 
keyboard  and  mouse  input.  The  servers 
then  are  the  only  display  dependent  part  of 
A'-Windows.  For  a  user  to  use  any  Ar-based 
application,  anywhere  on  a  network,  he  or 
she  needs  only  to  ensure  that  tiie  local 
display  (ie,  the  workstation  he  or  she  is 
using)  has  aX  server  available  and  running.2 

1  This  is  not  un  academic  or  theoretical  dis'-us- 
sion.  At  this  writing,  workstations  for  which  X  is 


Typical  client  applications  include  virtual 
terminal  emulators,  Tektronix  graphics  emu¬ 
lators,  calendar  and  mail  handling  tools,  text 
editors,  and  so  on  A  number  of  clients  are 
designed  to  provide  window/ menu/button 
interfaces  to  existing  general  and  special 
purpose  applications  package's. 

A  special  case  of  client  application  is 
tire  user's  wincbm  manager.  By  explicit 
design  decision,  A  does  not  enforce  any  pol¬ 
icy  about  what  the  look- and- feel  should  be. 
Instead,  the  window  manager  defines  how  a 
user  manipulates  window's,  and  may  provide 
tools  such  as  pop-up  menus,  scrollbars,  tides 
and  borders,  and  icons.  The  window 
manager  must  provide  a  mechanism  for 
moving  and  cycling  through  a  hierarchy  of 
windows,  and  m  conjunction  with  the  X 
server  mv-if  deal  with  requests  from  ;.pp!lca 
ti<  ns  for  new  windows,  selecting  graphics 
a,  d  text  tor  pasting  from  one  window  to 
••mother,  and  n  freshing  die  .-civen  after  a 
change.  Of  course,  applications  may  have 
their  own  user  interface  rules  tliat  differ 
from  each  other  mid  those  of  die  window 
manager  itself.  This  remains  one  of  die 
thornier  implementation  issues  for  tiu'  X 
develojx-r.  ’ 

Toolkits  .an'  collections  of  routines 
written  using  the  native  Xlib  subroutines 
allow  programmers  to  easily  include  such 
features  (or  “widgets”)  as  scrollbars, 
menus,  titlebars  and  bottlers  into  their  appli¬ 
cations.  To  an  extent,  these  sc-rve  to  create 
a  consistent  look-and-feel  across  multiple 
applications,  since  at  least  these1  widgets  look 
and  operate  in  die  same  way.  They  may 
also  provide  morn  special-purpose  capabili¬ 
ties  to  the  programmer,  such  as  color  table 
handling,  image  and  bitmap  manipulation, 
and  event  queue  polling.  At  this  time  a 
number  of  toolkits  are  available,  including 
the  X  Toolkit  from  MIT.  Camegie-Mellon’s 

fumnifin^v  list'd  ini/Judv  JJigiUil 
l^'iipim-ni  Micr>\ax,  Sun  Mk*r»s\sUams, 

Hvw  ’uckard,  Ap*l!o,  IBM  KT,  and  others; 
development  is  under  wa \  on  a  \  arietv  of  micro¬ 
computers  as  well.  Virtuiilly  all  workstation  ven¬ 
dors  have  committed  to  X- Windows  in  some  form. 

Then  are  now  some  attempt*  to  define  a  user 
interface  polio,  including  Sun/ AT&T’s  Open 
ls*tk AT&T  fArnvncjn  Telephone*  &  Telegraph 
f  o  rnpm;<  1  Hewlett- f'iu  karri’s  New  Wave, 

and  others 


A’icJmOguraNeuwirtli.  1986,  and  others 
Lee,  1988. 

The  actual  programming  effort 
involved  in  seemlessly  integrating  Git  ASS 
and  X- Windows  is  necessarily  a  phased  pro¬ 
ject.  Over  time,  X  functionality  will  be 
extended  from  simple  display  in  a 
networked  environment  to  completely  new' 
tools  based  on  an  .V- Window's  user  interface. 
At  the  same  time,  the  existing  base  of 
GLASS  databases  and  users  also  requires 
that  all  modifications  be  fuliy  upward  com¬ 
patible  with  current  implementations. 
Moreover,  GRASS  procedures  and  display 
manipulation  must  continue  to  bo  available 
on  platforms  oilier  than  X  workstations,  for 
example  ASCII  terminals  associated  with 
specialised  image  subsystems.  This  implies 
the  cn  lion  of  a  parallel,  rauu-i  ‘d.an 
replacement,  display  and  interface  system. 

The  initial  phase,  which  is  largely  com- 
p:<  te  ai  this  writing,  is  tlie  development  of  a 
n-,w  display  driver  that  communicates  with 
an  .V  server  on  a  host.  This  driver  simply 
takes  the  place  of  tiiose  tliat  provide  GRASS 
display  using  hardware-dependent  graphics 
software.  At  run-time,  the  grass- A  driver 
translates  the-  graphics  requests,  communi¬ 
cated  to  it  \aa  fife's  from  display  utilities, 
into  A- pro  to  col  syntax,  and  sends  them  to 
the  designated  server  via  sockets  or  11 V..  In 
this  initial  phase-,  there  is  no  change  to  the 
msterlib  which  generates  graphics  requests 
from  display  subroutines.  To  a  user,  there 
is  essentially  no  change  from  the  existing 
environment-  one  window  acts  as  a  control 
terminal  and  another  acts  as  a  display  sur¬ 
face. 

The  next  phase-  will  involve  a  more- 
complete  integration  of  the  two  display 
mechanisms.  This  essentially  requires  a  new 
version  of  insterlib  that  is  written  using 
direct  references  to  Xlib  graphics  calls,  rather 
than  to  the  device- independent  subroutines 
currently  used.  By  eliminating  the  “middle¬ 
man"  GRASS  driver,  the  rewritten  library 
should  substantially  increase  graphics  perfor¬ 
mance  over  the  initial  model.  Moreover, 
tlie  capabilities  of  this  new  “Xmsterlib”  can 
be  tuned  to  the  specific  features  of  the  A 
server  and  rely  on  resources  built  into  the 
server,  such  as  fonts  ( for  rapid  labeling)  or 


backing  stores  of  bitmaps  ifor  interactive 
real-time  graphics  overlay'. 

As  preliminary  work  lias  progressed  on 
designing  the  new  library,  it  has  become 
clear  that  the  its  functionality  takes  on  the 
characteristics  of  an  A'  toolkit.  As  a  social 
purpose  toolkit,  it  would  provide  the  CRASS 
programmer  the  building  blocks  necessary  to 
implement  display  utilities,  much  as  the 
existing  raster'll)  does  now.  In  combination 
with  general  purpose  toolkits,  Xiusterhh 
would  facilitate  entirely  new  ways  of  imple¬ 
menting  CRASS  capabilities,  including  multi¬ 
ple  display  windows,  more  sophisticated  use 
of  pup-up  menus,  property  sheets,  and  so 
on. 

New  user  mterface  proceduros  will  be 
implemented  in  a  subsequent  development 
phase,  once  tlie  Xjnsterlib  has  been  proven 
robust  and  reliable.  Gradually,  asCRASAV 
becarn  -s  mere  widely  list'd  and  available, 
users  at  varans  sites  will  be  able  to  generate 
their  •uvn  A'-bast  ri  utilities  and  tools,  reiving 
on  both  general  and  speciai-puqx.'se  toolkits. 

i  if  critical  concern  in  any  development 
program  is  the  design  of  a  user  interfV.ce  sys¬ 
tem  that  is  flexible,  powerful,  and  intuitive 
For  CRASS  also  inqiortant  is  maintaining  a 
consistent  interface  across  the  overall  user 
environment  and  particular  applications.  Ir. 
tandem,  these  restrictions  may  suggest.  tiie 
eventual  implementation  of  a  complete-  col- 
action  of  toolkits  that  not  only  handle  basic 
display  requirements  but  also  provide  v;iri- 
ous  widgets  for  tiie  CRASS  develojter. 
(obviously  tiie  design  and  implementation  of 
user  interface  toolkits  will  require  a  substan¬ 
tial  commitment  on  the  part  of  all  CRASS 
users  to  reach  consensus  a«  to  the  nature  of 
tin-  best  interface  model.  To  some  extent, 
the  overall  user  interface  design  may  be 
guided  by  various  proposes  being  con¬ 
sidered  by  Open  Software  Foundation  and 
other  groups. 

THE  GRASS- X  PARADIGM 
Modda  of  X-hasud  GiS 

Tiie  use  of  a  networked  windowing 
system,  such  as  A”- Windows,  in  conjunction 
with  any  interactive  C/S  package,  provides 
tiie  application  devel<qx>r  and  user  with 
several  options  Car  implementing  a  system. 


Such  flexibility  is  ensured  by  A- Window's' 
client-server  model,  in  which  every  system 
functions  as  a  server  with  respect  to  certain 
capabilities  and  a  client  with  respect  to  oth¬ 
ers.  Thus  a  designated  host  can  be  a  CRASS 
(or  other  CIS)  applications  server,  a  data¬ 
base  server,  a  cartographic  display  server,  or 
a  server  for  any  other  desired  purpose. 

The  first  model  of  the  CRASS- A  imple¬ 
mentation  made  possible  by  the  work 
described  in  the  previous  section  is  remote 
operation  with  local  X  service.  In  tins 
model,  all  processing  and  database 
analysis  is  performed  on  a  host  other  than 
the  users'  workstations:  the  workstation 
handies  only  tiie  actual  on-screen  display 
and  mouse/ keyboard  input.  The  remote 
system  supports  both  the  application 
software  and  die  spatial' attribute  data  for 
the  CIS.  The  system  may  be  optimized,  in 
hardware  and  software,  to  perform  CIS 
analysis  more  efficiently.  Software  needs  to 
be  supported  '  and  possibly  paid  for'  only  at 
one  site.  The  hardware  may  be  of  a  com¬ 
pletely  different  architecture,  using  a 
different  ope  rad  tig  system,  than  die  A- server 
workstation.  Indeed  die  local  display  system 
may  be  one  of  the  new  generation  of  A  ter¬ 
minals,  diat  provide  network- speed4  bit¬ 
mapped  displays  for  A'-ciient  applications, 
but  with  no  other  local  processing,  for  costs 
diat  have  now  dropped  to  below  $1000  per 
system. 

Ironically,  diis  model  is  analogous  to 
the  older  mainframe  computer-graphics  ter¬ 
minal  systems  that  workstations  are  begin¬ 
ning  to  replace.  In  genera],  requiring  one 
computer  to  perform  all  geo processing  func¬ 
tions  is  less  efficient  than  distributing  that 
processing,  but  tiiis  may  be  a  valid  model  in 
some  circumstances.  (For  example,  abroad 
community  of  users  may  make  occasional 
use  of  CIS  tools  for  simple  queries  or  ana¬ 
lyses,  and  even  in  their  aggregate  not  over¬ 
load  a  single  CIS  server./  Despite  possible 
inefficiencies,  this  model  is  still  superior  in 
many  respects  to  the  mainframe- terminal 
analog,  since  the  locai  workstations  can  still 
provide  windows  into  other  ser'ers  for  other 

1  For  example.  Ft  hornet  communication  i.c  ul 
n  maximum  rate  of  W  megabits/ second,  with  typi¬ 
cal  throughput  of  1  to  megabit*/ socn nd 


applications,  the  communication  with  other 
systems  is  typically  much  faster  than  serial 
terminals,  and  more  display  processing  is 
performed  locally,  offloading  low-level 
graphics  operations  from  the  primary'  (IIS 
host. 

The  second  < RASN-.Y  model  comprises 
a  distributed  GIS  implementation.  It  com¬ 
bines  centralized  (IIS  maintenance  with  local 
geoprocessing  operations.  A  user  at  a 
workstation  transparently  accesses  data 
residing  on  a  remote  host,  performing  any 
analytical  or  display  operations  on  the 
workstation  itself.  Although  invisible  to  die 
user,  the  needed  data  are  actually 
transferred  at  high  sjx'ed  across  the  network 
to  the  workstation  where  they  are  manipu¬ 
lated  by  software  that  resides  locally  (or  pos 
si'1  iy  on  yet  another  host  and  transferred  to 
lie  workstation: .  Then.1  are  at  least  two 
achnicai  methods  of  implementing  die 
■•mister  of  needed  data  and  software:  using 
relatively  iow-level  operating  system  pro - 
cedutvs,  such  a<  tiie  industry- standard  Net¬ 
work  File  System  (NFS);  or  using  intelligent 
data  windowing  or  extraction  techniques  on 
die  reinoie  host.  The  first  method  is 
currently  being  used  successfully  for  teach¬ 
ing  am!  research  projects  at  ('K')R.  It 
requires  die  least  effort  to  develop  and 
implement,  but  assumes  that  the  remote 
data  is  directly  manipulable  within  the  local 
software  environment. 

For  more  complex  siuiations,  'die 
second  method  should  ultimately  prove  die 
better  solution.  User- generated  requests  for 
data  would  automatically  bo  redirected  10 
the  remote  host's  native  data  retrieval  sub¬ 
system.  Appropnate  spatial/ attribute  infor¬ 
mation  would  be  extracted  on  the  remote 
(IIS  server  and  effectively  downloaded  for 
local  analysis  and  display.  An  extension  to 
this  method  could  also  facilitate  local  data¬ 
base  u|xlates  for  uploading  to  the  centralized 
server.  As  an  example  of  this  approach,  a 
fully-supported  (US  engine  using  ARCflnfo 
for  database  development,  maintenance,  and 
cartographic  production  could  provide 
query-determined  datafile  subsets  in  1)1. (I 
format  to  a  <  1 RASSY  workstation  located  in 
a  field  office.  There  the  user  could  perform 
rapid,  interactive  analyses  and  displays  on 
the  data  without  any  further  use  of  the 
AR('lnfo  server.  Obviously,  the  systematic 


application  of  such  technology  is  some  time 
off,  but  there  is  a  growing  recognition  of  the 
need  for  sophisticated  means  for  GIS  data 
and  software  sharing. 

The  third  model  for  using  GRASS-.Y  is 
a  stand-alone  mode.  In  this  case,  the  X- 
based  workstation  provides  all  data  develop¬ 
ment.  analysis,  display,  and  production 
functionality.  No  external  data,  software,  or 
hardware  is  required.  This  model  does  not 
offer  the  advantages  of  using  remote  sys¬ 
tems,  but  the  local  GIS  user  has  complete 
control  over  the  database  once  in  place.  A 
stand-alone  system  is  probably  most  applica¬ 
ble  for  smaller-  jurisdictions  or  organizations 
will  well-defined  missions  for  their  geo¬ 
graphic  information.  With  at  least  minimal 
communications  capability,  such  sites  could 
.hli  obtain  datasets  from  remote  locations 
on  .in  as- needed  basis. 

The  three  models  presented  are  con¬ 
ceptual  ones:  in  fact,  any  real-world  applica¬ 
tion  would  almost  certainly  use  some  combi¬ 
nation  of  tiie  three.  Some  database  com¬ 
ponents  would  be  maintained  locally,  while 
others  would  be  downloaded  from  central¬ 
ized  systems,  and  still  others  would  be 
manipulated  on  an  ad  hoc  basis  on  a  range 
of  distributed  systems.  The  real  value  of 
tiie  GRASS-X  paradigm  that  has  been  out¬ 
lined  is  in  lire  nbibty  to  combine  all  three 
models  in  creative  ways  driven  by  individual 
user  or  organization  requirements. 

G RASS-X  Advantages  and  Disadvantages 

Although  many  aspects  of  tiie  distri¬ 
buted  models  described  above  could  be 
implemented  under  a  variety  of  G1S  and  net¬ 
work  systems,  tire  specific  features  of  both 
GRASS  and  X-Wmdows  offer  unique  advan¬ 
tages  to  the  system  developer  and  user.  In 
some  situations  these  may  be  sufficient  to 
provide  complete  GIS  capability;  in  others 
they  may  be  used  as  a  gateway  into  even 
greater  GIS  functionality  and  data.  Again, 
actual  implementations  will  rely  on  a  combi¬ 
nation  of  these  two  modes. 

GRASS  has  been  designed  from  the 
outset  to  work  well  in  a  workstation 
environment,  and  thus  is  a  logical  vehicle 
for  entering  a  distributed  GIS.  Especially 
when  a  number  of  installations  are  contem¬ 
plated,  GRASS  lias  tiie  additional  advantage 
of  being  essentially  free.  This  does  imply 


that  organizations  milking  a  significant  com¬ 
mitment  to  LRASK  must  also  maintain  tiie 
internal  resources  for  installing  and  operat- 
ing  the  software.  Since  ( ;  It  ASS'  is  it  very 
developmental  systtmi,  new  capabilities  are 
added  regularly  and  new  subsystems  must 
be  supported. 

Compared  to  other  systems.  C.ltASS  is 
relatively  easy'  to  learn  and  use,  and  there¬ 
fore  can  be  used  at  remote  sites  without 
extensive  internal  support.  Note  that  this 
observation  applies  to  the  use  of  >  id  ASS 
softuarv.  It  is  critical  to  romembet  that 
intelligent  use1  of  CIS  requires  sophisticated 
understanding  of  the  relationship.-:  among 
environmental  features,  of  vho  naturc  <:f  car¬ 
tographic  representations  of  tiie  landsc.ipe. 
and  of  tiie  explicit  characteristics  of  ti’o 
spatial  attribute  database  being  used.  As 
Nancy  Tosta  of  die  California  Division  <>t 
Forestty  has  observed  i  personal  eommuni 
cation  ■,  "t,!s  do*-s  not  supjx.m  naiv^  users." 
Kasy  to  use  soft .van*  s u.b  as  Lit  \ss  some¬ 
times  has  the  unde.-ared  hue  affect  of  v-na 
Wing  inappropriate  us*-  of  .  ompiex  CIS 
applications. 

A'- Windows  is  analogous  to  (lit ASS 
bo tli  in  terms  of  its  workstation  orientation 
and  its  public  domain  status.  It  is  available 
on  virtually  all  major  workstation  platfomis. 
and  is  beginning  to  appear  on  smaller  sys¬ 
tems  as  well  Since  it  is  based  on  UNIX  and 
on  approved  communications  standards,  it 
also  lends  itself  to  direct  incorporation  with 
l  it  ass. 

Since  A’- Windows  provides  both  net¬ 
work  and  windowing  capabilities,  it  enables 
( dt  A  AS- AT  to  operate  in  several  modes  simul¬ 
taneously.  That  is,  one  display  window  may 
be  showing  a  map  generated  from  a  local 
CRASS  datafile,  while  another  represents 
data  on  a  remote  system.  Moreover,  a 
variety  of  remote  network  nodes  may  be 
accessed  at  once  through  different  windows, 
and  in  fact,  a  typical  user  session  may  easily 
utilize  resources  held  on  ten  or  morn  com¬ 
puter:.  Of  course,  these  do  not  need  to  be 
only  CIS  applications  or  data-  many  types  of 
tools,  such  as  document  processing,  elec¬ 
tronic  mail,  statistical  analysis,  and  so  forth, 
may  be  accessed  concurrently.  The  local  A' 
server  handles  tire  text,  graphics,  keyboard 
input,  mouse  manipulation,  and  other 
events  automatically. 


A'  is  still  a  developmental  system,  and 
has  not  stabilized  to  the  point  of  some  com¬ 
mercial  products.  Although  there  is  a  com¬ 
mitment  to  upward  compatibility,  the  very 
nature  of  its  extensibility  implies  that  some¬ 
what  divergent  X  environments  will  emerge. 
At  this  writing  a  number  of  developers  are 
competing  to  establish  common  toolkits, 
user  interface  designs,  and  programming 
standards,  so  the  future  is  not  entirely  clear. 
Vendors  are  also  attempting  to  optimize  X- 
servers,  in  particular,  to  their  hardware 
environment,  and  sometimes  hardware- 
independence  suffers  as  a  result. 

future. Et'jcairii  Directions 

Some  of  tiie  major  avenues  for 
research  are  suggested  in  the  preceding  para¬ 
graphs.  including  an  examination  of  the  fun¬ 
damental  .vquirements  for  a  flexible  and 
[xrv  rfui  user  interface  and  mechanisms  for 
facilitating  intelligent  retrieval  of  informa¬ 
tion  from  diverse*  data  sources  around  a  net¬ 
work.  Research  is  proceeding  at  Berkeley 
and  elsewlierc  in  numerous  related  domains, 
but  little  effort  has  been  expended  to  date 
on  relating  these*  to  (IIS  in  general  or  to 
LHASA  or  X Windows  in  particular.  Fields 
of  endeavor  we  hojx-  to  turn  to  in  the  future 
include: 

<  'ooniiuute-.Daa.'d.  Query.  Work  is 
already  undeivvay  to  allow  use  of  digitial 
majis  as  indices  to  a  broad  variety  of  infor¬ 
mation.  including  imagery,  landscape  photo¬ 
graphs,  archival  materials,  published  and 
automated  maps,  etc.  A  logical  extension  of 
this  capability  is  to  enable  coordinate-based 
queiy  lie.,  by  pointing  at  a  map  location)  of 
(dS  data  layers  that  may  exist  at  any  defined 
location  within  a  network.  Currently,  a  user 
must  have  prior  knowledge  of  what  data  are 
available  and  where.  Linking  in  an 
automated  index  could  increase  by  orders  of 
magnitude  the  volume  and  range  of  infor¬ 
mation  effectively  available  at  a  site. 

and  hypermedia  tools  allow  intuitive  link¬ 
ages  to  be  built  between  disparate  data  ele¬ 
ments;  each  element  can  be  in  a  completely 
different  form,  including  maps,  images,  text, 
spreadsheets,  and  so  forth.  Integrating 
these  tools  with  fundamental  LIS  capabilities 
provides  policy  and  decision  makers  with 
significantly  more  power  to  browse*  through 
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geographic  information  and  explore  relation- 
sliips  between  environmental  features. 

Fix  pert  Systems.  As  the  range  of  (IIS 
data  becomes  more  distributed  and  as  GIS 
software  becomes  easier  to  use,  more 
sophisticated  user  agents  will  be  required 
These  user  agents  intelligently  process 
queries,  identifying  the  GIS  data  most 
appropriate  to  answering  the  question  at 
hand  and  performing  the  necessary  analyses. 
Expert  systems  technology  is  already  in  use 
in  other  domains,  but  the  transfer  of  that 
technology'  to  GIS  is  complicated  by  the  very 
complexity'  of  geographic  information. 

Object-Oriented  Databases.  Current 
ivsearch  in  database  management  systems 
t  DBMS)  is  focussing  on  object-oriented  data¬ 
bases.  Object-orientation  essentially  defines 
‘•very  entity  in  the  database  as  an  object, 
■ncompassing  features  such  as  dimension, 
relation  to  other  objects,  hierarchical  ascen- 
ri.tncy  and  descendancy,  topical  connections, 
and  so  forth.  Since  geographic  entities 
almost  by  definition  include  all  these  charac¬ 
teristics  and  more,  they  arc  a  logical  candi¬ 
date  for  incorporation  with  object-oriented 
DBMS.  Currently,  work  is  underway  on 
linking  postgrvs ,  and  object-oriented  succes¬ 
sor  to  the  Ingres  relational  DBMS,  to  geo¬ 
graphic  information. 

Though  these  future  directions  tire  not 
necessarily  tied  to  either  GRASS  or  X- 
Windows,  both  systems  appear  to  be 
appropriate  vehicles  for  exploration.  GRASS 
source  code  is  freely  available  to  researchers 
and  can  be  modified  without  restriction;  its 
modularity  also  lends  itself  to  advanced 
work.  X- Windows  is  also  freely  available, 
and  much  of  the  work  in  the  areas  outlined 
above  is  already  based  on  X.  By  providing  a 
strong  linkage  between  GRASS  and  X,  we 
hope  to  create  a  platform  for  examining 
these  and  other  options. 

CONCLUSIONS 

'Ihe  open  systems  approach  of  GRASS 
to  GIS  power,  flexibility,  and  interactiveness 
is  well-matched  to  the  network  extensibility 
and  hardware-independence  of  X-Windows. 
This  combination  provides  the  GIS 
developer  and  user  with  the  ability  to  per¬ 
form  complex  geographic  analyses  on  any 


node  on  a  data  communications  network 
while  displaying  the  results  on  a  local  works¬ 
tation,  to  systematically  extract  information 
from  distributed  databases  and  analyze  and 
display  geographic  information  locally,  and 
to  maintain  and  manipulate  entire  GIS  appli¬ 
cations  in  a  stand-alone  environment.  The 
combination  also  provides  a  useful  platform 
for  research  into  new'  GIS  technologies. 
Together,  tire  models  for  GRASS-X  imple¬ 
mentation  and  research  constitute  a  new 
paradigm  for  distributed  Geographic  Infor¬ 
mation  Systems. 


REFERENCES 

AT&T  (American  Telephone  &  Telegraph 
Company),  1988  AT&T  (American 
Telephone  &  Telegraph  Company) 
Open  Look  PM  Graphical  User  Inter¬ 
face  Functional  Specifications  July 
1988  Sun  Microsystems,  Inc.  200 
pages 

CERL.  1987  CERL  An  Introduction  to 
GRASS  13  pages.  US  Army  Construc¬ 
tion  Engineering  Research  Laboratory' 
Champaign,  III  1987  Environmental 
Division 

CERL,  1987  CERL  Library  of  Resources 
GRASS/ GIS  US  Army  Construction 
Engineering  Research  Laboratory 
Champaign,  Ill  1987  Environmental 
Division 

Goran.  1987  Goran  GRASS  and  GIS  Tech¬ 
nology  Corps  Applications  1987 

Hack,1987  Hack  The  Advantages  of  X  Com¬ 
puter  Graphics  World  6,  57-60  August, 
1987 

Lee,  1988  Lee  Window  of  Opportunity 
LTNIX  Review  46-61  pages  1988 

Ogura  Neuwirth,1986  Ogura  Neuwirth  The 
Andrew  System,  Programmer’s  Guide 
to  the  Base  Environment,  Version  2 
Information  Technology  Center,  Car¬ 
negie  Mellon  University  Pittsburgh 
1986  IBM  Corporation 

Scheifler  Gettys,1986  Scheifler  Gettys  The 
X  Window  System  ACM  Transactions 
on  Graphics  79-109  1986 

Westervelt  et  ah,  1987  Westervelt  Shapiro 
Higgins  Larson  Programmer's  Refer- 


71  - 


ence  Manual  US  Army  Construction 
Engineering  Research  Laboratory 
Champaign,  Ill  1987  Environmental 
Division 


USACERL  DISTRIBUTION 


Chief  of  Engineers 
A ITN:  CEIM-S1.  (2) 

ATTN:  CECC-P 
ATTN:  CKCW 
ATTN:  CECW-O 
ATTN:  CECW-P 
A  ITN:  CECW  RR 
ATTN:  CKEC 
ATTN:  CEEC-C 
ATTN  CEEC-E 
ATTN.  CERD 
AT I  N:  C!  RIM' 

ATTN  CERD-M 
ATIN  CERM 
ATTN:  DAF.NZCF 
ATPN  DAENZCI 
ATTN':  DAHNZCM 
ATI'N  DAEN-ZCZ 

C'i  I'SC  ATTN:  (  EHSC-ZC  22060 
A  ITN.  DE'T  III  79V06 
AT'N  CEHSC-F  22060 
I  N:  CEIISC-TE  22060 

N  Canadian  Liaison  Officer  65*03 
'  V  German  Liaison  Staff  65473 
*  "IN  French  Liaison  Officer  65473 
A  IT  N:  Water  Resources  Ceruir  22060 

ITS  Army  Engineer  Districts 
A  ITN  Library  (41) 

L'S  Army  F.ngr  Divisions 
ATTN:  Library  (14) 

L'S  Army  Europe 
ODCS, Engineer  09403 
ATTN  AEAEN-FE 
ATTN:  AEAF.N 
V  Corps 

ATrN  DEH  (II) 

VII  Corps 

ATTN  :  DEI  I  (16) 

2 1  si  Support  Command 
ATI'N:  DEH  (12) 

I  SA  Berlin 
ATTN  DEII  (9) 

Allied  Command  Europe  (ACE) 

ATTN:  ACSC.EB  09011 
ATTN  Slfil  IH/Engmcer  09055 
ATI'N:  AEL'ES  09081 

L'SASITAF 

A  TTN.  AKSET'N  D  09019 
tth  I'VA,  Korea  (19) 

KOK'A.S  Combined  Forces  Command  96301 
ATTN1:  EUSA-HHC  CI  CTlingr 

I  SA  Japan  (USARJ) 

AITN  DCSEN  96343 
AITS:  Facilities  Engineer  96343 
ATT  N  DEII  Okinawa  96331 

Area  Engineer,  AEDC-Aieu  Office 
Arnold  Air  Force  Suuon,  TN  37389 

4!6ih  Engineer  Command  60623 
ATTN  Facilities  Engineer 

I  S  Mtitary  Academy  10966 
ATTN  Facilities  Engineer 
ATIN:  Dept  of  Geography  & 

Computer  Science 
ATfN:  MAENA 

AMC  Dir  .  Inst  ,  A  Svcs 
ATTN-  DEII  (23) 


DLA  ATTN:  DLAW1  22304 
DNA  ATrN:  NADS  20305 
FORSCOM 

FORSCOM  Engineer,  ATI'N:  Spt  Del. 
ATTN:  Facilities  Engineer  (27) 

HSC 

Ft  Sam  Houston  AMC  78234 
ATI'N:  HSLO-F 
Fitzstmons  AMC  80045 
ATTN:  IlSHG-DEH 
Waiter  Reed  AMC  20307 
ATTN  Facilities  Engineer 

INSCOM  •  Ch,  Iristl.  Div. 

Arlutgion  Hall  Station  (4)  22212 
ATTN '  Facilities  Engineer 
Vint  HilJ  Farms  Seal. on  22186 
AITN  IAV-DFH 

USA  AMCCOM  61299 
ATTN:  AMSMC-RI 
AITN:  AMSMCIS 

Military  Dtst  ot  Washington 
ATTN  DEH 

Cameron  Station  (3)  22314 
Fort  Ixsley  J.  McNair  20319 
Fort  Myer  22211 

Military  Traffic  Mgmt  Command 
Falls  Church  20315 
Oakland  Army  Base  94626 
Bayonne  07002 
Sunny  Point  MOT  28461 

NARADCGM.  ATrN:  DRDNA-F  01760 

TARCOM,  Fac,  Div.  43090 

TRADOC 

1IQ,  'fRADOC,  ATTN:  ATEN-DF.I  I  23651 
AITN:  DEH  (18) 

TSARCOM,  ATTN:  STSAS-F  63120 
USAIS 

Fort  Huachuca  85613 
ATTN:  Facilities  Engineer  (3) 

Fort  Ritchie  21719 

WESTCOM 
Fort  Shifter  96858 
ATTN:  DEH 
ATTN:  APIN-A 


SHAPE  09055 

ATTN'  Survivability  Sect.  CCB-OPS 
ATTN.  Infrastructure  Branch,  EANDA 

1IQ  USEUCOM  09128 


ATTN: 

ECJ  4/7  EOF 

Fort  Bel  voir,  VA  22063 

ATIN: 

Bnush  Liaison  Officer 

ATrN: 

Australian  Liaison  Officer 

ATTN 

Kngr  Studies  Center 

ATTN: 

Engr  Topographic  Lab 

ATTN: 

ATZA-TH-SW 

AITN 

STRflE-BLLRE 

CECRI.  ATTN:  Library  03755 
WES.  ATTN:  Library  3918 
HQ,  XVBI  Airborne  Corps  and 


R  Bragg  28307 
ATTN:  AFZA-DEH-EE 

Chanute  AFB,  IL  61868 
3345  CES/DE,  Stop  27 


Norton  AFB,  CA  92409 
ATTN:  AFRCE-MX/DE 

TyndaU  AFB,  IL  32403 
AFESC/Enginecring  &  Service  Lab 

NAVFAC 

ATTN:  Division  Offices  (11) 

ATTN:  Factliues  Engr  Cmd  (9) 

ATTN:  Navsl  Public  Works  Or  (9) 
ATTN:  Naval  Civil  Engr  Lah  (31 
ATTN:  Nava]  Constr  Battalion  Ctr 

Engineering  Societies  Library 
New  York.  NY  10017 

National  Guard  Bureau  20310 
Installation  Division 

US  Government  Printing  Other  22j04 
Receiving/Deposiioiy  Section  (2) 

US  Army  Env.  Hygiene  Agency 
ATTN-  HSHB-ME  21010 

Nal’l  Institute  of  Standards  &  Tech  20899 

Defense  Technical  Info.  Center  22314 
ATTN:  DDA  (2) 


316 

09/89 


